Two types of developers: deliberate v. intrepid
The meeting of two personalities is like the contact of two chemical substances: if there is any reaction, both are transformed.
If nine years in software development has taught me anything, it’s that there are more kinds of developers than there are projects they work on.
Developers proudly wear all kinds of adjectives to proclaim themselves. You have front-end devs and server-side devs, hackers and computer scientists, architects and bug-squashers, and team leads and solo rock stars. The list goes on and on—we all have ways of referencing the developers around us. Such is the nomenclature that we use to categorize our peers.
Today I would like to focus on a particular, and often problematic, dichotomy—the relationship between two types of delvelopers: deliberate and intrepid.
We all know deliberate developers. Deliberate developers like their backlog to be planned and curated. They can point to a detailed JIRA ticket justifying their work. They want to understand how their work fits into the bigger picture. Deliberate developers often balk at pull requests that are too large. They don't like accidental success, and they want to diagnose failure. Perhaps most notably, they are likely to stand guard against scope creep. A good idea should take its turn in the queue of other good ideas.
We also know the intrepid developers. They will jump on a good idea regardless of who pitched it. They own work rather than let a backlog own it. They are skeptical of process and meetings—they rely on personal communication to convey their status. They get antsy when they don't feel like they are getting anything done. Maybe the most distinct characteristic of intrepid developers is that they don't let unknowns stop them from embarking on a journey. They cross those bridges when they get to them.
Or, at least, those are more positive aspects of these two archetypes.
All too often, we focus on the negative: to us deliberate developers become too rigid and beholden to process, or perhaps unwilling to adapt to changing priorities. They can be labeled as inflexible, or perhaps even thought of as unwilling to commit to a lofty goal. Maybe the dreaded 'waterfall' word will rear its ugly head.
Similarly, we often label intrepid developers as reckless or distracted. All too often they seem in a hurry or are thought to be acting without a good plan. Maybe we believe their behavior isn't considering long term needs sufficiently. Perhaps most damning of all is when we say intrepid developers don't care about architecture.
Because of our focus on the negative, there is little that can cause more team tension than asking deliberate and intrepid devs to work together. They often focus on the worst traits of the other. Rarely do they appreciate which of their own weaknesses are bolstered by that other.
As a dev manager, this is my chief concern: How do I get these equally valuable people to work together? We all need to acknowledge powerful models—even when they are not our own. Instead of focusing on the ways in which we are different, we should focus on the ways those differences can get us to the same goals.
These are both potent types of developers, and they can work perfectly in concert:
- We should have a deliberate business model asking intrepid development teams to tackle a new proposal and quickly evaluate its feasibility.
- It makes sense to have deliberate architects farming out prototyping to intrepid developers on their teams.
- Deliberate tech leads can use their expertise to guide intrepid developers and allow them to move quickly.
There is a lot to be gained by aligning these powerful models in the right way.
Instead of railing against the bad habits we see in others, ask ourselves what can we learn.
- Is a given ritual needed?
- Can you own something to completion and focus on delivering something good rather than treating projects as just a list of todos?
- Are you actually weighing risk or always assuming it?
- Are you challenging yourself?
- Is your speed actually inefficient in the long term?
- Will your work need to be redone when we talk to another team?
- Are you solving on the right problem?
- Do people understand what you are working on and your progress?
Let’s take a cue from Carl Jung. We’re already having a reaction—it might as well be one that leaves us all transformed. We should use these experiences to make ourselves better developers. We should all be parts of two types of developers—both deliberate and intrepid—we just have to find the balance.