Hackers v.s. coders

In my 20 years of experience in software industry, I have met two kinds of programmers. Although they all call themselves software engineers or programmers, they exhibit very different behaviors and ways of thinking when it comes to programming.

I call the first kind “coders”, and the second kind “hackers”.

How do “coders” think and behave?

Coders put a lot of emphasis on “the code”. When I’m talking to them, I can clearly see that they think the code is 80% of what matters when it comes to building software.

• They tend to be very strict about coding style. “Absolutely no lines can be longer than 120 characters.” “No magic numbers or magic strings whatsoever.”
• They love design patters and layers of abstraction. “We should use Abstract Factory here.” “Let’s future-prove our code so that we don’t have to change it in case we change the data model.”
• They usually rave about TDD (Test-Driven-Development), code review, unit tests.
• They ask algorithm questions when interviewing their future colleagues.
• They care a lot about the performance of the code before the code goes live. “Hey you are creating a new object every time this service is called. Let’s cache it.”
• They are very opinionated about programming languages and platforms. “You can’t build a large system with dynamic-typing language or else it’ll be a disaster.”

How do “hackers” think and behave?

Hackers cares more about how software runs in production and serve users.

• They are pretty “sloppy” about coding styles. Hard-coded constants everywhere. Mix of OO and procedural coding doesn’t bother them too much.
• They prefer straightforward design and loathe many layers of abstractions. Some of them can’t even name any design patterns beyond Singleton. “It drives me crazy when I have been tracing this bug through 7 layers of call hierarchy and still can’t find where the exception is thrown!”
• They care more about speed and how robust the software runs in production than about “best practices”. “How many bugs have our unit tests caught that would otherwise have gone to production?” “How much has the PR review process benefited us while doubling the time for the code to go out?”
• They are terrible at algorithm questions when they go to job interviews. Therefore they don’t ask them when they are at the other side of the table.
• They don’t care too much about the performance of the code until it hits the production. “I really don’t know if this for-loop will be slow until I measure it in production.”
• They are usually fine with whatever programming languages thrown at them. But they are opinionated about software engineering principles. “Measure before you optimize.” “Keep It Simple and Stupid.”

Who are “better” programmers? Coders or hackers?

I know this statement may cause a lot of controversy, but IMHO, hackers are far more superior than coders when it comes to building softwares.

I used to be a coder and I was proud of myself for my “craftsmanship of the code”. It was when I was only a cog in a really big wheel and never saw the end-2-end process to build, run, and maintain a complex software system. I never knew how my code had run in production because it was several departments and a few hundreds people away from me. I just received an issue ticket and it was not clear to me at all how the production was monitored and how issues were identified, triaged, and prioritized. In other words, I couldn’t care anything but how perfect my code was. It was 100% of my job. Most coders are like the old me.

I quickly abandoned my coder mind and converted to a hacker after I started my own company. I had to do figure out the most effective way to build and run the whole system. It was when I started to ask myself:

Is the 20% of extra time I spent on writing unit tests worth it?

Will using a Decorator make the code more robust and easier to debug in production, or the opposite?

Does an engineer candidate’s ability to answer questions about binary tree have anything to do with releasing to production as fast as we can, with as few bugs as we can?

It made me realize the code, which I used to think was 80% of the software, is at best 20%. What’s far more important is the ability to understand the characteristics of the problems in hand, to quickly research the available tools and objectively evaluate them, to come up with an effective way to operate and monitor the finished system in production. This is the key reason why hackers and coders think and behave so differently.

I am working only with hackers now because it can’t be more clear to me that “serverless architecture is the hottest thing and everyone is doing it now” means nothing to me. Getting features built fast and run in production without issues does.

I need the ones who can see the whole forest, not just the trees.