Somewhere, sometime ago, someone came up with the term rockstar programmer. Perhaps like most catchy terms in our industry, it started out as an innocent idea, was bastardized by just the right people, and ultimately became the marketing ick that it is today.
Programming isn't about one-person wrecking crews, save for those pet projects you're just dabbling with on the side. Yet, some businesses still look for that mystical rockstar programmer to right all their existing wrongs. They have a heap of work to do, that heap is likely on fire right now, and they need someone to f**ing rock the s**t out of it! How y'all doing Deeeeetroit?!
I've never seen good, solid software created with this kind of mentality. The work that goes into writing good code is arduous. It takes time. It takes contemplation and cooperation. More experienced programmers might know where more of the traps exist, but they still need time to think the problem through. Anyone can build something that appears to work for a short while, but the real work lies in making it work (or reliably adjust it to work) for the long-term. Otherwise, the business just goes into a perpetual game of “Who wants to be the next David Lee Roth for awhile?”
Even more importantly, good software teams can't be built around one-person shows. When I think of people that build good software, I think of a rock star's musical antithesis: the band itself. The best teams are small (say 2-5 members). And, they stick together. They know each member's tendencies because they've worked together for a long time. They know when to leave each other alone to nurture their piece of the product, and when to (yes), “get the band back together” at the right times. To me, that's the easiest way to guarantee a hit product: Create a tightly-knit group that's willing to stick it out for the long term, together.
The best part about building software with a small, loyal team is that it absolves you from having to apply a myriad of processes–those that are otherwise essential for a group of technical individuals unfamiliar with each other to function at all. When teams are real small and have worked together for years, “people processes” like formalized sprints, scrums, or complex version control strategies are overkill. All of these tactics are meant to impose a consistent influx of ritualistic order onto an impending chaos. And, impending chaos happens to teams that are constantly turning over team members–whether or not there's a rockstar amongst them.
Granted, small, long-lasting teams are not immune to marching down the normal dark paths of programming. Codebases still gets crufty. The forces of change still push code into unwieldy shapes. But, in these teams, getting out of the muck is much easier. The mindshare of what the intentions were, what tradeoffs were made, and how the realities came to be likely still exist in the minds of its team members. The methodical route to elegant code comes with less friction because you've all been in the battle together.
Long-lived programming teams are rarely heralded in our industry. Similarly, cohesion and camaraderie amongst coders is severely underrated. What we have, instead, is a culture which champions the individual and focuses on forcing process to minimize the impact of the inevitable churn of a team's developers.
If, alternatively, we championed the aging band instead of the rockstar, perhaps we'd also indirectly extinguish the perceived need for the mythical rockstar.
Republished with permission from Life Imitates Code.
Top comments (0)