Which is a rebuttal to something I didn't actually say, but OK.

Look, obviously there are all different kinds of programmers. Millions and millions of people program computers today, so there's no end to the ways you can slice them apart. There are kernel programmers and GUI programmers, mainframe programmers and mobile programmers, Lisp programmers and BASIC programmers, elite programmers and n00b programmers.

But they are all programmers, was my point. They all do the work of wrestling with, as one of the people in Tracy Kidder's classic The Soul of a New Machine (http://www.amazon.com/The-Soul-A-New-Machine/dp/0316491977) called it, "La Machine."

In this respect, being a programmer is a lot like being a coal miner: you become one by doing the work. Sure, some miners are handier with a pickaxe than others, and some can stand being down in a dark hole for longer. But regardless of that, everyone who puts on a hard hat with a lamp on it and goes into the mountain is a coal miner. The only thing you have to do to earn the designation is show up and do the work.

Now for the part of my comment where I (respectfully) challenge your conclusions.

You want to divide "programmers" further, into (essentially) "programmers," who are lazy 9-to-5 stumblebums, and "REAL programmers," who code with burning fury 23.5 hours a day (the other .5 hours they spend on HN). And then tell the people outside the "REAL programmers" category that, sure, they're "programmers," but they're not programmer programmers.

But that has a value judgment embedded in it, namely that 23.5-hour-a-day Burning Fury programming is Good Programming, and 9-to-5 programming is Bad Programming. But those positions aren't good or bad, they're just embraces of different sets of tradeoffs. You note yourself that the Burning Fury programmer sacrifices her health and relationships to get to that level. The 9-to-5 person is just someone who has decided against making that sacrifice. Maybe that limits their career growth, but it lets them hold on to those things. Maybe you've decided to let those things go in order to accomplish more in your work.

And both those decisions are fine! I'm not here to tell you how to live your life. I'm just saying that your way of being a programmer is not the only way of being a programmer. There are lots of ways to be a programmer. The only thing they all require is that you do the work.

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.

A "copy-and-paste JavaScript" developer, as I referenced above, is someone who can create web pages that have simple actions, but who doesn't do much original development.

The language certainly doesn't define the programmer. I also use JavaScript on occasion; I wasn't trying to paint all JavaScript developers with the same brush.

It sounds like what you do is NOT what I'm talking about, so please don't take offense.

I write games, and tools to make games, and tools to stream interactive applications over the Internet. And apps. And the occasional web site.

Perhaps there is something to your point -- I doubt there are nearly as many successful "copy and paste C++ developers" (although I have met at least one). It might be harder to cobble together even a barely-working piece of software from StackOverflow C++ posts.

Blew me away to discover this when I sat down to help him debug an algorithm that he had, in fact (correctly) copied from somewhere else, but then he'd slaughtered it trying to "make it work." Most of the fixes involved reverting his changes, and then making a couple minor modifications that WERE actually necessary.

He'd been fighting with it for a couple days. I had it streaming sound in about 15 minutes. Based on his words to me after the fact, he was really just not understanding what the code was doing. Pretty much at all.

That said, he did have some good insight into user interface design. I could see that he did have some important skill sets, but understanding how to manipulate memory in C was not one of them. Whether he was a "successful" developer is debatable, since he didn't hold the position, though.

I'm sure that "copy and paste" developers exist for most common languages. I've heard from several sources that finding a non-copy-and-paste developer who uses JavaScript is a real rarity. I've also been told that Google in particular is looking for that skill set. Sounds like you could write you own ticket. :)

I tend to divide programmers into "drones" and "meta-drones" (for want of better words).

First, "meta-drones" consider the "meta" level of programming, i.e. "could I program more reliably if I were using a different language?" or "how can I prevent myself from making similar mistakes in the future". Surprisingly few programmers actually fall into this category. This is obviously IME, so the usual observer/survivor biases may apply.

In contrast, a "drone" will just "get the job done" without any further thought.

As far as I've been able to ascertain, code maintainability/quality is entirely orthogonal to the "archetype", but there's a clear tendency that the "meta-drone" tends to improve by orders of magnitude over time.

The number of hours of work put in has no significant effect when you account for those orders of magnitude.

I really don't like this euphemism. When I read this I know what you mean[0] but I wish this meaning wasn't tied to leaving the office at 5pm. If someone's effective in their role, why should they be judged on what time they leave? This mentality doesn't encourage people to work harder or be better employees, it only encourages them to stay later. That eats into their free time every day, giving them less opportunity to relax and recharge and probably causing them to become less productive and more prone to burnout in the long run.

If I can get my job done by 4pm every day then don't force me to sit at my desk until 6pm to keep up appearances. Either let me go home or help me fill my time by offering me more work (and if I'm highly productive, more compensation).

[0] The person is only putting in the bare minimum effort, has no interest in personal development, is more interested in the paycheck than craftsmanship and professionalism, etc.

However, I've been thinking about this recently - the logical extreme is that you should never expect the employee to turn up at work at all, provided he performs his tasks (say via telecommuting). Perhaps employers mandate 'desk time' because it's important to have regular physical access to the employee, for example in order to talk to him? I can think of HR/legal reasons where a private in-person interview is needed in order to inform the employee of something or to retrieve information from him. Consequently, if an employee only came in to work for these meetings, it would be obvious when the employee was engaged in some sort of 'serious' communication with the company. It would make mass layoffs especially conspicuous and difficult for the company to hide.