I Hate Puzzles: Am I Still a Programmer? (2011)

Without calling one group "REAL", it would be nice to have different words for different tiers of programmers.

And I can't comment on the poster above, but when I do think of programming skill tiers, it's not at all about number of hours put in.

Yes, if you're passionate about a problem it can mean you end up putting in extra time to solve it. But it's not about the time. It's about the passion.

Similarly, it's not calling the leave-at-5pm programmers lazy. To them it's a job, and maybe even a job they're good at. I spend a lot of time living life outside of work, and I (usually) end up quitting after only about a normal day's work.

But I also get more done in my work day than 98% of "programmers". And the reason is that I've had a consuming passion to learn about programming techniques, tools, algorithms, and even logic puzzles, ever since I can remember. So some of that free time involves reading about programming; if I enjoy it, then it certainly counts as living my life. When I don't feel like learning something about coding, I do something else in my varied set of hobbies and interests.

The reason it would be nice to have different words for different tiers of programmers is that what I do is qualitatively different than what the copy-and-paste JavaScript writer is doing. I can certainly call myself a software engineer, or a game developer, or a graphics engineer, or a low-level programmer, but none of those really encapsulate it all; I also hit high performance server development, database optimization, networking, encryption/security, video streaming, and petal-to-the-metal assembly language optimization when necessary (though that's a skill that's less and less useful these days). And on top of that I write tools that help optimize the software development process for myself and my team.

When I look at what I do vs. what a junior front-end web developer does, calling what I do the "same" as what the junior developer does is somewhat akin to calling an assistant handyman and an engineer who designs skyscrapers or rockets or nuclear reactors "both engineers, because they both help build things!". All that extra work the engineer puts in to learn and hone his trade should be worth something, and having a title for it does help.

Something that bothers me about your coal miner analogy: The best possible coal miner is likely not more than 2x-3x better than the worst. Brooks' famous 10x performance difference only captures a small part of the real difference: There are things that I can do that a JavaScript developer simply can't do, no matter how much time they put in. Brooks was only measuring people trying to accomplish similar tasks, after all. And I'm not talking about domain expertise; I also follow and keep up with JavaScript and front-end development, and it's just orders-of-magnitude simpler than what I code on a weekly basis.

And I do find that puzzle solving (though not the physical kind) does correlate pretty well with the ability to do the high-end, hard-core programming that I do. I certainly am good at both, and it would be hard to imagine how I could solve the complex algorithmic issues that I solve on a daily basis if I couldn't think clearly about logic puzzles.

Diversity is a strength, and I have learned this managing several teams of varying sizes over the years for different companies, as well as for myself.

I have heard many start up advisers tell people to 'hire people you like to hang out with'. This isn't the best advice. Personality is extremely important, and you don't want to hire people who will be incredibly difficult or toxic or adversarial. But you need different people in different roles, with different viewpoints, to make a strong team.

Puzzles: One clear solution Algorithms: "Better" solutions. "Best" solution may exist but hard to definitively prove. Often, things like cost and time are real constraints in the solution to the problem. Real world "problems"/"design": solutions are optimized for a certain set of outcomes.

I don't like puzzles either, but I think it's due to their restrictive nature and generally non-creative solution finding process. I prefer making puzzles over solving them.

We need more of this. I played baseball and basketball and yes, I also played chess. I'm not an introvert (although I do love alone time). This narrow idea of what traits a good programmer has is the fault of Eric Raymond who when describing what kind of person is a good hacker was clearly just describing himself (interested in martial arts, plays a musical instrument and speaks a foreign language, all perfectly great interests but what makes them better than cooking or chess or painting?). While it's great to have hobbies that involve critical thinking, nothing about the going stereotype of a programmer is necessary to be a good programmer or good thinker.

Imagine if there was an equally narrow stereotype about what kind of person is a good doctor or lawyer. Doesn't that seem ridiculous? What about programming is different? Nothing. It seems so absurd to me that as an industry we're telling interested parties that diverse interests are a bad thing if you're a programmer and you should just stick to a short list of approved interests. No wonder there's no diversity in our field.

Agreed. Some people say you'll only use it in games or AI or something fancier, but that's not entirely true. I work with what would be considered pretty boring enterprise software, and yet I once solved a pretty big problem using graph algorithms. That actually earned me a good reputation among my coworkers.