Programmers come in all different shapes and sizes, but there’s one way to partition them that’s particularly interesting to me. I’ll call them code-aware programmers and result-aware programmers.
Code-aware programmers
Code before all else. These coders are big on standards and usually operate in an us (programmers) versus them (stakeholders) paradigm. They will push back against the business when the business requests something that could potentially degrade the code. They tend to grossly overestimate the lifecycle of the software they’re working on by favoring extensibility in the extreme.
Result-aware programmers
Results before all else. These coders will write code in a pragmatic way and will keep abstraction to a minimum. They’ll strictly adhere to standards insofar as they allow them to get their code through peer review, but their eyes are typically on the prize for the duration of their project. They tend to work with the business, and comply with the demands of other programmers to the extent that it will allow them to successfully complete their tasks.
Because there’s little awareness of these different breeds of coders, we will occasionally find ourselves working with people that all fall firmly within one category. In the case of code-aware programmers this can be a real problem, since agreement on standards and which libraries to use can cause a lot of strife. I’ve seen people literally quit their job over disagreements in chosen libraries, so it would be an understatement to say that code-aware programmers are opinionated.
It’s not surprising, then, that code-aware programmers are often higher up in the pecking order: It’s easy to mistake strong opinions for strong experience. Without trying to sound too antagonistic, I think that such code-aware programmers should be a rarity within a company.
Unfortunately, it’s the result-aware programmers that are the rarity. Why? I have a couple of theories. First, it’s easy to communicate authority over other programmers by telling them how they’re doing it wrong. Second, it’s easy to express to the business how a project is failing because of deteriorating code standards (“if only those idiots would listen to me, we wouldn’t be in this mess!”). You may have little actual experience, but you can certainly con people (wittingly or unwittingly) into thinking you have a lot of experience by following those two simple steps.
The real backbone of a project is the programmer who will actually sit down and do the work without analyzing the thing to death, and will allow other programmers to do the same. This is what being agile is all about. This is the result-aware programmer. Do the work, and if you’re going to fail, then fail fast and try again. If you feel the urge to condemn someone’s work or put the project on standby for technical reasons, try to be honest and make sure you have the experience to truly back it up.
I will write more on this last point (i.e., honesty) in future posts, because I think it’s critical to job satisfaction and productivity. I may talk about it in the context of my own life (programming), but I imagine it’s similarly effective no matter what you’re doing.
The Simple Coder 