In response to one of Anne’s recent bookmarks — every pro-office (a room, not Microsoft) coders favorite study — Christopher Mahan leave a nice reply about the Super Code Monkey:
No, the 10,000 times more productive developer is the one who has the experience, the guts, the curiosity, the hard-headedness and the stick-to-itiveness to go forth and take over entirely unchartered territories.This developer has carefully selected his tools, mastered his environment, from the idiosyncrasies of his OS, to writing lexical parsers for his language of choice in his language of choice, to tackling problems that to management seem like utter wastes of time but that could resolve a obscure bug on an obscure product, a bug so obscure it has only occurred three times in the History of Computing. Yet, it is in this utter dedication to that task that the brain trains itself to be devastatingly thorough, to anticipate the impact of every single byte on the expected result, to watch in his mind’s eye avenues of opportunities and dead-end boulevards unfold ever-forward, beyond release date, beyond maintenance and product end-of-life, all the way to its ultimate impact on the common psyche of programmers, as tricks of the trade and techniques passed from generation to generation.
In my programming life, my concern has been Everyone Else. While the above is spot on for the guru and the coder with the well developed “mind’s eye,” that still leaves the other 80-90% of the programming world. These are the people who are either not:
- super-brillant by way of base skill or lack of passion and energy to be so
- and/or cannot set the context of their development such that they can shine.
There’s a third category (hinted at by the first), and that’s (usually) older people who’ve realized it’s not that important to worry about it unless you’re running your own company.
In mature software projects, combating all three of those is a constant, difficult, and dangerous task for managers:
- Constant because everyone grows older and looses that youthful passion for coding and Doing the Right Thing.
- Difficult because keeping that youthful passion going to counter to what we consider a “normal” life (in Western society at least).
- Dangerous because you encourage burn-out and risk offending people who want to go home to see their kid.
Ultimately, I’d posit that most software companies are not willing to pay programmers enough money or share in enough profit to sustain the sort of passionate coders you’d “want” and that people like Paul Graham chronicle, fund, and profit from. Good for him and the coders! The Grahamian programmer, as much as I really like the model, is not really the majority programmer, yet most (vocal) code-monkeys, and certainly, the rest of the world, like to think/wish it is.
Passion on the Balance Sheet
Jumping to the end — there’s a lot of hand-waving to insert here — the result for me is that I don’t trust any “normal” philosophy of software development that depends on passion and “youthful energy.” I prefix that with “normal” to exclude people who are Going for the Gold, that is, startups where coders can get insanely rich. The expectation there is that the company is buying your burn-out, so you better work every waking hour for the next 1-2 years to make that money. (Good luck, sucka’s!)
Now, don’t get me too wrong here: I’m not saying that certain endeavors can’t rely on passionate coders, just that not most software projects can’t rely on it whole-sale. As a manager, team, or individual, you have to use that passion as a tool to motivate coders to work and to do good work. But, years of software success and failure have given me a jaundiced view of the expectation that passion and those with mind’s eyes alone will help you deliver the software, if only because there’s so little of that passion out there to hire.
The XP guys had a great gate for this thinking with their 40 hour work week limit. Of all the practices in XP that got ignored — even above the dread paired programming! — that one was immediately jettisoned, and it’s telling of the basic expectations of everyone in the field. I mean, 40 hours isn’t even enough time for all the coffee drinking I do in a week. Come on!
Widen the Focus
Tell me what you have, and that’s when I’ll know if you have anything to start with…
What I’m trying to say more is to step back from the role of the coder, even the development manager, and ask what sort of system and context the company or team working on the project is. How does it work, how much can it be changed, and what can any given actor do with those two levers? Rather than simply saying “you need passionate coders,” what additional methods of getting the code out the door and (if applicable) sold are available? This isn’t to dismiss the role of the programmer at all. Rather, it’s to make sure that all the effort put into the software is used rather than scuttled by the rest of the organization. Put another way: I’ve seen the software efforts of passionate coders wasted when the rest of the organization was not as carefully optimized as the writing of the software. Tragic!
Technorati Tags: codemonkey, programming, xp, peopleware, work, passion
Not sure I understand this line:
> Constant because everyone grows older and looses that youthful
> passion for coding and Doing the Right Thing.
Can you explain what you mean by 'Doing the Right Thing'?
My phrasing was clearly laxed as I'm nodding to what you're typing 😉 My example was crappy and seemed to narrow down to doing more work in a cowboy-coder fashion instead of figuring out an over-all process that prevents having to do that. Which leads too hopefully a better example:
As you point out, developing software and developing the process that goes along with it requires a lot of energy to not only figure out what the right thing to do (code or organization wise) is, but to actually expend the energy to make sure it gets done.
So, if you determine that doing things iteratively is The Right Thing, and yet your team doesn't do things that way, there's a certainly amount of energy to spend to change things.
Now, the passionate employee will spend that energy, going up against the metaphoric brick wall of change resistance until either (a.) they effect change, (b.) they leave, or, more likely, (c.) they figure out how to subvert the resistance to change and do The Right Thing anyhow.
The larger point is that I'm suspecious of organizations that don't make that sort of review, consider, and change part of their culture. Instead they rely on (intentionally or not) heros putting in the effort to change without help from the company.
Now, narrowing down the software development, the thing that rubs me the wrong way about the "just get really good coders" line of thought is that it doesn't seem like a reliable, long term way to make software. There are not enough of those people to go around, more than likely they won't stick with you over the life of the product, and, as you point out, there are process adjustments to make to deliver software that don't rely on heroics from employees.
I suppose the prime assumption here is that an organization doing software has to be oriented around changing the process as called for by the context, where the context is not only the traditional customer inputs (requirements and stories), but also the internal "requirements" and constraints of the company itself.
Now, that's all obvious and good, but it's the point in most everything I read where you start to get a lot of hand-waving and clever answers instead of pragmatic how-to's.
How's that for a crack at it?
This still puts the Passionate Coder on a pedestal as if that's the holy grail but sometimes we settle for less. That's wrong I think. It ignores that the team is the context – the PC isn't a world unto him/herself – they are likely part of a team and that team may be depending on them. So, when they chase some obscure bug that will never affect a real user of the software and slip other tasks that people are depending on, they're NOT "doing the right thing" they're indulging their perfectionist side. I'd much rather see a coder with the ability to note that bug, finish stuff that the team needs and then fix it later (or to be able to explain why it actually does need to be fixed NOW).
Let's stop putting the perfectionist obsessive at the top of the pyramid… they can be valuable, and they will often make a product much better over time, but they're not some ultimate standard – they're simply one style of coder. Useful, perhaps critical in some cases, but to elevate them above the rest of the team is an affront to people who may care very much about their code and their product… but who chose not to stay up until 3am fixing the most obscure bug ever.
Passionate Coders (herein referred to as PCs) are valuable not for their direct output but the effect they have on the rest of the team. There is something magical about working next to one of these PCs because they have a skill and methodology that's only gained from being OCD. With proper mentoring (and I would further posit that all PCs strive to be good mentors, all others are poseurs…) a "normal" coder can better leverage his "40 hours and a mule". What's unfortunate is that management tends to view PCs only terms of their direct output ("Wow! Billy wrote the whole accounting module in one night with only a toothbrush and a can of jolt! Imagine what we could do if we had an army of these!!"). As I can personally attest to, working with somebody brilliant can have profound influences on the way you view not only the project but sometimes the career. The PCs is like the raisons in a raison oatmeal cookie. It’s counter productive to make your cookie 100% out of raisons (and defies the laws of cookie physics) but it’s nice to have one or two for "spice"
Re: effecting change, I think it starts with getting the right leaders in place. If a project or organization has bad leadership, and you're not in a position to change that leadership, then it's better to leave than try to change it.
I categorize bad leadership in two ways:
– bad intentions (e.g. goal is individual acknowledgment and power hoarding, CYA and blame if something goes wrong)
– ineptitude (e.g. good intentions but don't have the mental, emotional, or technical talent to succeed)
In the first case, it's probably impossible to effect change, in the second case it may be possible but it could take a very long time.
But if you have good leadership (talented + right intentioned), you're probably doing a lot of the right things already, and the organization will be amenable to change because you're intent on doing the right thing and also you're smart and confident enough to respond positively when one of your employees (or you yourself) spot suboptimal parts of your process.
So I guess my philosophy is if you're smart enough to recognize the attributes of a healthy software development organization and you're not currently in a healthy software dev org, quit your job and go to a healthy env, because it's a futile exercise to change an org lead by folks who are either too incapable or ill-intentioned to have already fixed the org.
Note that a highly productive development organization doesn't necessarily mean you work 80 hours a week. I work for what I consider to be a very productive team and heck, I still find time for the occasional blog comment 😉
Hah! You caught my laziness: tragically fitting to the point.
What I meant was putting in the time to do the something that would take more effort but be a better solution when there was a easier solution available. Being quality instead of being cheap” and getting home on time.
I actually disagree with this. If you work in an organization that does frequent iterations, it’s often better to do something that’s fragile but will allow you to get something working, and then circle back to make the design more robust later.
Oftentimes the motivation for this is that you’re working on a feature and there are too many unknown unknowns to really make informed design decisions, so the trick is to quickly work through a first iteration, kludges and all, gain understanding and experience from the effort, and use this new understanding to make an informed design/implementation decision later.
The risk of ‘doing the right thing’ in the face of unknown unknowns is that is that if you end up re-defining the problem you’re trying to solve (as you often do upon reflection), your fast/robust/secure solution now lacks an even more important property … relevance.
Once you decide that indeed you’re solving the right problem and you understand the key design constraints – usually after 2-4 iterations, it’s a good idea to do the right thing and make your design fast/robust/secure.
PS – If any of your iterations span a release to customers, then of course the equation shifts back towards ‘doing the right thing’, even if you have to chuck that extra work later, esp. w/r/t security.
Rick: yup, that’s the right sentiment. And, indeed, as I tried to clarify in the second response to Bill, this whole doing the right thing crutch (on my part) was more an intention of spending the energy and risking the back-lash to suggest and work for change. The larger point being that a company can’t depend on every employee, forever battling to change. Instead, software organizations need to make it part of the culture and welcome.
Again, totally obvious in an intuitive sort of way, but in my experience, hard as hell to actually implement.
@Daniel: mmm… cookies…
@Cote: our comments crossed in the ether – I just read your reply to Bill… all is right with the universe again. 🙂
@Bill: I'd add one more tweak to the leadership picture – talented, right intentioned, but not aware of something new. Since there are multiple forms of the Right Thing, they may settle into something that is working well. The PC can act like a scout – they're more likely to be aware of leading edge ideas, techniques, etc. A good leadership will be receptive, even if they choose not to adopt every suggestion.
Rick said:
> I’d add one more tweak to the leadership
> picture – talented, right intentioned,
> but not aware of something new.
Good point Rick. I also think that this is an important attribute for all team members, not just leaders.
One of the criteria I use when hiring developers is: do they read technical blogs? I've found that people who read technical blogs tend to be much more aware of emerging trends and technologies – as you said, not to chase every buzzword but to have a general awareness of what's happening as an input to identifying and pursuing promising emerging technologies.