Mature Developers

Written by Benjamin Reitzammer on May 12, 20159 minute read

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.

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.

Having and Sharing a Technical Vision

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?

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.

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.