Mature Developers

This article is cross-posted from squeakyvessel.com

Some time ago, as I started to spend more time on growing our tech team at vaamo again, I realized that I had put off one thing for much too long already: Putting down my definition of maturity and technical leadership in software teams.

In order to get this finally sorted out, I’ll lay out the aspects that together make up a mature developer.

What Defines a Mature Developer?

A developer’s maturity is mainly defined by their soft-skills, less so by their technical abilities and knowledge.

The assumption underlying this postulate being, that it’s very unlikely for a person to combine most of the below mentioned maturity traits without going through some years of working in teams, in which the technical skills will likely get sorted out one way or another.

But what actually are those characteristics, soft-skills that make up mature developers?

Mindfulness

Mindfulness is a simple practice that can be described as paying attention to what is going on in the moment, without judgment.

And I strongly believe there’s a meaningful correlation between one’s ability and willingness to pay attention, to self-reflect and their ability to improve themselves and those around them.

So one of the first and most important qualities of mature developers is they’re more often than not paying attention to what is going on around them. They’re deliberately taking their time to observe before proceeding (put succinctly as STOP; Stop, Take a breath, Observe, Proceed).

Mature developers are being mindful about themselves and their surrounding, in order to be able to always keep improving their own work and approaches, and of those around them.

Mindfulness sooner or later leads mature developers to become aware of, learn about cognitive biases and find ways to handle them.

Curiousity

Technology work is creative work. And I simply can’t imagine someone being good at it, by any measure, without being curious. Curious about the surrounding technology, about how things work, about why things are the way they are etc etc.

And this curiousity should not diminish over time. Rather it should always grow alongside maturity, as one is exposed to more problems, technologies and people over time.

And it’s also important that this curiousity is not limited to technical topics only. Mature developers are curious about people, how they tick, what’s interesting to them and much more.

Pragmatism

The necessary counter-balance for curiousity is pragmatism. As one is curious about almost anything, they usually need to choose quickly about what’s important and when it’s important.

More generally, a pragmatic developer weighs possible options in terms of long-term impact and costs vs short-term benefits.

However, what’s hard about this skill, is that it’s very much driven by intuition. After some amount of experience, one has a basis to which current decisions can compared, in order to decide for outcomes that are less likely to work vs those that have a higher chance of success.

Pro-Activeness

Personally my first and still trusted indicator of a good developer is pro-activeness.

Someone who is pro-active communicates early & often. When discovering new information, learning something new they think about who this new information affects and act on it.

Furthermore pro-active developers seek out risks, they see chances way before they are obvious for others, which can help a team succeed much faster and more easily.

Where should the systems that people are working on lead to? How do you know it’s a success? What’s there to do, beyond the obvious stuff, that’s needed to get features out the door in the next three months and beyond and what’s the thinking and reasoning behind those visionary aspects?

Not the least part of having this technical vision is then also to actually share it with relevant people. Ideally with anybody who is even remotely involved in working with or shaping the system in the future. This means people like product managers etc should also know about the vision.

Sharing the vision with other involved parties not only serves as a perfect opportunity for practicing one’s skills to explain deeply technical terms and circumstances with non-technical people. It also serves the purpose to validate the vision in terms of relevance to business value and other aspects.

Understanding Business Value

Mature developers know and understand at every turn, that everything they do serves the purpose of providing value to someone else, most of the times some kind of business and with that, some kind of customer.

They’re able to put everything they do into a greater context of their business and understand how their current and future actions play out into this context.

Because of that they can empathize much better with non-technical people. Which in turn enables them to communicate and explain their actions and motivations more easily and usually concisely to non-technical people, and reduces friction when working with non-technical people.

Reasonable Risk-taking & Decisiveness

Putting their actions and plans into a bigger, non-technical context also enables mature developers to better assess risks. For example, does the risk of introducing a new technology possibly outweigh the business benefits that are to be expected?

Assessing and understanding risks better puts them into a position where it’s also more likely they’ll actually take risks. Risks which, without the knowledge about business value and the bigger context, may look too big to be worthwhile. But not for mature developers who are able to see beyond the obvious risks and include more aspects into their judgement.

Reasonable risk-taking furthermore involves excellent communications because assumptions must be made about the intended outcome of risk taken, and incomplete data leading to the decision for taking a risk must be accompanied by another set of assumptions. Mature developers, know that both kinds of assumptions must be communicated to others in order to raise the chance for the risk-taking to be worthwhile.

Lastly the ability to take reasonable risks requires a certain amount of determination, of decisiveness. Because while it’s all nice & easy to theorize about decisions that involve risks, at some point decisions need to be made on incomplete data, on assumptions. And mature developers must be comfortable with that. Mature developers have to like making decisions.

Empathy

Empathy is noticing, and better even knowing, the situation another person is in.

And it’s really is one of my favourite words and concepts. Without empathy you cannot be effective or even successful in working together with others.

You need to be empathic to resolve more conflicts than you create and therefore providing value to and with others. So empathy is an absolutely required skill for mature developers.

Empathy enables understanding others’ goals. But before that, one must have a real interest in getting to know their peers. What is it that motivates them? What do they get passionate about? What makes them happy? What frustrates them? Knowing those things about someone actually means having a somewhat real relationship with that person. And that is the basis for empathizing with them.

Without a relationship with that other person, you can still try to know about someone else’s situation, but you’re making assumptions at best if you don’t know the other person. And your assumptions will be wrong. Probably more often than not.

Another aspect which makes empathy an easy concept in theory but more complex in reality is, that it can and is easily mistaken with sympathy. Sympathy is empathy plus actually feeling the other person’s feelings. Which is not always helpful. It may even be confusing, because it may reinforce your belief that your assumptions about another person’s situation are correct. (h/t to Oren Ellenbogen for making this distinction clear to me)

Excellent Communicator

I’ve touched on mature developers being good communicators earlier already, but of course this deserves to stand on it’s own.

Mature developers communicate excellently by always taking the context of their communicating peers into account. They know or at least have a sense about their counterpart’s goals, their state of mind, sometimes maybe even the mood they’re in, and how their peers usually communicate.

This allows them to consciously choose the way they communicate with others. Does my counterpart need a direct and quick answer, or do they want to understand the surrounding details? Do they want a short answer now, but more info later on? Is it useful for my and my counterpart’s goals to take a more defensive stance right now, in order to relax a situation?

Put simply: Always know what your counterparts need and want to know. And deliver it.

When taking into account the context of your communicating peer and the situation you both share, one important detail often gets overlooked: Assumptions.

Making your own assumptions explicit towards your counterpart, asking for the other’s assumption usually makes communicating so much clearer. Not only faster by reducing possible misunderstandings, but also less of an effort and possibly less stressful, because with assumptions laid out the communication can focus on what’s to be done, and less about establishing a common understanding first.

Other Opinions

As with most things, many people have come before me and shared their view and they influenced my thinking or helped me shape my own way.

And rather than thinking my definition above is new or novel, you can view it as a prioritized extract and sometimes slight rewording of those originals. So when describing my own understanding in the above paragraphs I haven’t pointed to the exact references anymore. I’ll leave it to the interested reader as an exercise to find out where exactly I copied from.

The most comprehensive and absolute must-read on the topic is John Allspaw’s “On being a Senior Engineer”. It’s not only a testament to an amazing amount of clear thinking on behalf of the author, but is amazingly comprehensive and already a timeless classic. And I owe John Allspaw’s writing a lot, in that it broadened my horizon and gave words to a lot of things that were only unconscious before.

Some much more recent pieces on the topic of Tech Leads such as “Good Tech Lead, Bad Tech Lead”, “No Tech Lead”, a lot of stuff by Pat Kua and the ever-excellent “Leading Snowflakes” by Oren Ellenbogen they all provided loads of inspiration.
As well lots of very good reads from Kate Madsudeira as well her timeless talk on leveling up your engineering and operations role.

Of course, many more opinions, such as talking with my colleague Timo, with members of the local Softwerkskammer and at many a SoCraTes conferences, influenced my thinking, but those are the most prominent ones.