Brave Developers

Cautious developers keep the software world turning. They are careful, detail-oriented and inject fewer bugs than the others. This post is not about them.

This will be about the brave coders. They are the foolish risk takers. They can each point to a system they have managed to completely break at some point in their career. In some ways, they are a hazard to the very systems they work on.

And we need more of them.

Not only do brave coders inject more bugs, they are less concerned about creating them in the first place. In a counterintuitive way, this means that they keep our codebases clean. That sounds like bullshit, i know. Here is why.

The good, bad and ugly

Make a list of the best and worst things to have in a codebase. I did, and then i ordered them. My list is as follows:

Notice bugs are the least of our problems in a codebase. Secondly, is the high level pattern of the bad items: the more something impacts maintainability, the bigger the problem it represents.

And here is where the foolish among us become so useful.

Brave coders are driven mad by the worst of the Bad column and are excited by the prospect of eliminating them. To them, the risk of bug injection is a lesser concern compared to the prospect of unmaintainable code in a codebase. And good thing: i don't know of a single example of someone tackling an undocumented legacy system without breaking some ancillary feature along the way.

This fearlessness lets them attack bastions of unmaintainable code others would [perhaps rightly] ignore. What they trade for higher bug injection is the reduction of some greater evils: bad architecture and undocumented legacy systems.

But balance is key. Brave coders en masse are a dangerous thing and something to be actively avoided. Also, letting them work unfettered can have some harsh consequences on a codebase.

One useful practice to measure their chutzpah is to team them with some cautious devs on one of their projects. Making them work with a detail-oriented dev or two can gain you a lot of the benefits of the bravery while protecting a codebase against some of their brazen foolishness.

Identity and balance

For the same reason it's important to know who on your team are introvert or extroverts, knowing who are your brave and cautious cohorts is valuable. The easiest way to identify someone is their focus: brave coders have no fear working on the worst items in your codebase. They are the distinct minority.

Cautious coders, on the other hand, tend to be nervous as they venture too far up the Bad column. In many ways, TDD and its "Red, Green, Refactor" movement was created to help cautious coders tread carefully into the technical debt world. To be clear: these are good traits. I only want 1 brave coder for every 4 or 5 cautious ones on my team.

But make no mistake: both are essential to a high functioning team. Cautious coders keep our bug injection low and brave devs keep the system quality high. In a team's velocity spectrum, cautious devs keep the ceiling high. Brave devs push the floor closer to that ceiling.

These brave fools

If your team doesn't have a brave dev onboard, it may be time to find one. In my experience, they tend to be young trailblazers. We grow more cautious over time. Eventually we may all become the old curmudgeons who have had our bravery beaten into submission by our own failures. But to those who hang onto their bravery, know that it is valuable.

Steve Jobs famously quoted a country road sign that read: "Stay Hungry, Stay Foolish". I doubt very much he was referring to bulldozing unmaintainable software components, but he just as well could have been.