To Win Before You Code

avb1I know several über coders that would start a private printer server with: gcc -xc -;./a.out&, type for 90 seconds and their server would be up and running. I like them, the are generally fun people. I would never hire them though. It’s like having your car gassed up for free and find out they welded the gas tank shut. avb2 I would hire the kind that would think and than write (or download) some code and refactor it until it was solid. That is like having your car gassed up for half price and find out your car now runs a 100 miles to the gallon. Or maybe I would not hire anyone by the hour, but simply use something like ”Programmers are most effective when they avoid writing code. [...] The romantic image of an über-programmer is someone who fires up Emacs [or IYFEH], types like a machine gun, and delivers a flawless final product from scratch. a A more accurate image would be someone who stares quietly into space for a few minutes and then says ‘Hmm. I think I’ve seen something like this before’ (John D. Cook) [Why programmers are not paid in proportion to their productivity]. Managers love to reward according to measure. But code productivity is hard, if not impossible, to measure. If team productivity is hard to figure out, it’s even harder to measure the contribution of individuals on that team. You can get a rough sense of a team’s output by looking at how many features they deliver per iteration. b It’s a crude sense, but you can get a sense of whether a team’s speeding up, or a rough sense if one team is more productive than another. But individual contributions are much harder to assess. While some people may be responsible for implementing features, others may play a supporting role – helping others to implement their features. Their contribution is that they are raising the whole team’s productivity – but it’s very hard to get a sense of their individual output unless you are a developer on that team (Martin Fowler) [Cannot Measure Productivity].