There’s more than one way to skin a cat, or so they say. Similarly, perhaps, there are many ways to successfully lead a development team, small or large. Having done the former in various capacities I’ve learnt a lot about people, myself included, and there’s one conclusion I can’t ignore: it’s a fickle business. Books like the oft-praised The Pragmatic Programmer
lend the wisdom of elder programmers and analysts (which reads somewhat like a Carnegie self-help book, but I’m only a third of the way through) who’ve done and seen it all. Nothing keeps you learning like the real thing though…I’m still inexperienced; I can still learn more; I can always do better.
If I were to share one lesson, it would be what I coin “The Blind Fireman“.
The comparison
Programming solo or in a team is complex. It requires concentration, analysis, open communication, rubber ducks, knowledge of the language you’re using (or not), knowledge of what you’re producing, knowledge of your users, knowledge of your tools and so on; it favours the experienced, those who’ve done it wrong in the past and learnt the hard way. Little wonder, then, that it’s difficult to get it right first time, if at all. Taking all of this into account should affirm how complex the situation is. How much effort and understanding it takes to succeed in getting a product out the door. I think in some ways this is why what someone once said “complexity has nothing to do with intelligence, simplicity does” is so relevant.
Now fire-fighting is surely more complex. It’s certainly far more dangerous than sitting at a desk 8 hours a day pondering APIs, inheritance and polymorphism. I imagine it takes bravery, concentration, analysis, teamwork, tools, knowledge, risks; use certain tactics and equipment for various different types of fires, temperatures, environments.It sounds far-fetched, therefore to even mention a programmer and a fireman/woman in the same arena professionally, but consider the following if you will…
The story
You’re a fire-fighter (woo hoo!). You’re sitting down and sipping a cup of tea at the Fire Station, reading the local paper when suddenly the alarm goes off: there’s a massive fire at the local furniture factory. Parts of a three story building are ablaze and people are trapped inside. You gear up, jump in the fire engine and head to the scene.
Fast forward a bit and you’ve taken the briefing from the chief fire-fighter. The fire’s on the second floor. You’re climbing the stairs in your equipment; mask, tank and the like. Looking upwards you can see there’s a lot of smoke. It’s crawling along the ceiling slowly. Swirling and swishing its way around. You reach the top of the stairs and you realise you can’t see much, if at all. Where’s the fire? How would you know? You feel your way along the corridors; your only indicators are the heat emanating from the room ahead and the roaring sound of sofas and chairs being devoured. One of your main sensors – sight – is out of action, how do you stop the fire? Do you keep going? Do you communicate with your team? Both? Would being able to see just make the challenge a whole lot easier? How about a nice, cheap but reliable pair of thermal imaging goggles, complete with HUD and video cam for relaying what you’re seeing to the team outside? [Granted that's all easier said than done]
The explanation
Though extreme, I see this analogy as a warning for lead developers on the importance of “getting their hands dirty” when heading up development efforts on a new or existing code base; for the managers of such people on recommendations to their senior programmers and a suggestion to be made by those under either of the two. Don’t design blind!
The fireman/woman lost one of their main senses, and this adds to the complexity and difficulty of the situation or task at hand.
How can you decide what code needs changing – where, how much and why – if you’re not writing code in the first place? How can you steer your co-developers in the right direction programmatically/design-wise/tool-wise if you’re not using what they’re talking about?
To put it another way: can you really trust your design decisions if you don’t use what you create? How will you know it works in reality? When it’s too late?
The conclusion
It’s easy to get get bogged down in the politics, analysis and organisation of programmer leadership; perplexed, pressured and warped by the needs, wants, desires and craziness of “the business” (your users!). Resist it all and set yourself programming tasks at every stage of the project, because seeing the fire is half the struggle to putting it out in the first place.