Subtitle: And why it matters.

This is sort of self-perspective post, because honestly, if it weren't for me not being a real programmer, I'd never found out the difference and the good sides in both. And understanding of this thing is like self-diagnosing yourself and choosing the best way to go, which you probably would want to do earlier.

Now, let me first say, that being one type does not automatically means you don't have the wow moments of another type. From my experience it's like a slider: the more you have this thing the less you have another. And keep in mind you don't have any events pre-attached to the slider so it takes hard work to actually move it.

So, what's a real programmer? I believe it's the one who's obsessed with the programming itself, not with the result. It's the guy who would spam your IM with tons of code and discussions about it 4 times out 5 when you have a conversation. I don't think it's bad or totally boring, but it's just not as much fun for the other type. So, for a real programmer the result of his work still matters, but not as much and usually it depends on how satisfied he is with the code he's actually produced. On the other hand, the dude who knows how to do this knows this for a reason - and the reasons are usually his own projects which are (hopefully) an infinite source of motivation for him. A real programmer finds motivation in simply learning new things and that's usually the reason they master many technologies and languages, while the dudes stick to a single one. That's why they get good jobs at companies for a fine amount of money and do not complain every day like wusses about how working for someone else sucks. Of course it does not mean they're destined to work their whole life like that - they can still quit and start their own company, but probably not as much because they want more money and their own business, but more because they disagree with, say, the corporate policy for brackets {} style.

But here's a really weird thing: it's dangerous to have both in one room working on the same thing. The real programmer would most certainly outperform the second guy at writing the code and this will inevitably lead to a significant loss of performance in the dude. Of course the dude will learn a lot, but that's not what he really wants. Not as much at least. The project is really fragile when you're starting it and it's really a bad idea to allow one person who cares more about the code then the business to take over it (and vice versa). Remember how the team performance is measured by the most looser in it? Now think about who would do better: two dudes who know how to do it or 1 dude with lower than usual productivity and a real programmer? What I'm trying to say is that there are different types of tasks and projects - there are technically complicated ones that only real programmers can crack and there are tasks which only dudes can manage to keep above the water in the sea of the code.

This simple theory (or call it a model) of 2 types of programmers should really help when choosing the right partner to work with. I would argue that 2 entirely different type of programmers would manage to deliver the project - all because of the productivity gap. So be careful before you (mentally) commit to the project. Hope this helps.

If you liked this post, please follow me on twitter: http://twitter.com/romansnitko