Towards happier developers

(Subtitled – This is not another mental health/diversity post)

While I acknowledge how important mental health and diversity are, I am not going to talk about either. Instead, I’m going to talk about ways that we can make all developers on our teams feel more comfortable and productive. While developer happiness and mental health/diversity are directly related, this post will be about the business case behind truly happy developers.

Definitions first

While it’s easy to define developer happiness (at least on a gut level), it is harder to come up with a formal definition or a way to measure whether developers are happy. Some of the best measures that I have found look at sick leave and how frequently they refer other developers to fill job openings. However, both of these have problems. The first is that many developers are most productive in spurts and in some cases, they will finish three weeks of work in a weekend, then compensate by taking some sick time. Is that a sign of an unhappy disengaged developer or the opposite? The second problem is that counting referrals assume that all your developers have a steady stream of talented friends who want jobs.

Instead, what if we look at how willing developers are to put in extra work when shit goes off the rails. Hopefully, you’ll never get the chance to measure this, but when things get bad, happy developers tend to be willing to put the time in to get it fixed before it impacts production. I don’t think this is a function of how happy they are to be working for you, or how proud they feel to be part of a company. Instead, I feel like they’re happy enough that they don’t want to ruin that regular happiness with any kind of stress. Engaged developers will solve a crisis and fix the underlying problem because they want to stay engaged on solving fun problems, not responding to outages with overflowing support queues.

Can we call this the avoiding bullshit metric? If so, what will we call it on slides in pitch decks?

With that aside, let’s look at some techniques for maximizing developer happiness and productivity.

1. Build a culture of learning

Software development leaders have a choice they must make early on. They must either foster a culture of constant learning and change, or of constant telling. If they foster a culture of constant learning, they must be open to being wrong and to learning from even the most inexperienced developers. If they foster a culture of constant telling, they must always be correct, or their projects may fail.

Between the two, a culture of learning is the most productive because it acknowledges the role that rules have upon creative thought. Sometimes, design patterns can get in the way of creative solutions, so encourage all developers to just hack out solutions and figure out the code quality and efficiency later. Another positive step is to ask developers why they think their solutions are correct, before you tell them why they are wrong? Worst case scenario, you will learn a better way to solve a problem. Best case scenario, you will understand how more junior developers think and be able to do a better job of mentoring them to think like professional software developers.

2. Celebrate “I don’t know”

This is the other side of building a culture of learning, but it’s important enough to state separately. Ultimately, there are two extremes in software development cultures. There are cultures where everyone acts like they know everything, and cultures where everyone is proud to admit they don’t know something.

When developers pretend to know things they don’t, they risk wasting time figuring out suboptimal solutions. While that sort of exploration can be valuable from a learning perspective, it’s often more efficient to get confused developers started off on the right path. When a culture celebrates “I don’t know”, it helps make learning more efficient while celebrating modesty. Which leads into number three.

3. Be kind

There are cultures where scathing criticism is the norm. I believe this is the greatest problem in software development today. The problem with scathing criticism is that you make experimentation scary, and you impose a cost to making suggestions. If your new suggestion is not well thought out, or if it is at the more senior developer just does not understand it, scathing criticism is both embarrassing and silencing.

Because of this, it is vitally important to be kind when people are wrong and take the time to explain why other approaches are better. If you approach these conversations with humility, you can learn incredible new things while building up your developers and encouraging them to be kind when put in similar situations.

If given the choice between working with kind developers and brilliant jerks, the vast majority of us would choose to collaborate with the kind. Finally, if you truly love code, make the point of learning your co-workers’ birthdays and always celebrate them. Play pranks, take them out for lunch, bring cake or even bring in a card, but always recognize your co-workers’ birthdays. The sad thing about code is that it’s so solitary, that years later you’ll often discover you were the only person who wished that person a happy birthday.

Wrapping it all up

I presented three simple strategies for making developers happier. Based on my experience, adapting these three approaches, with the correct tools will lead to better code and larger profit margins. You can earn these gains by promoting a culture where everyone feels comfortable contributing to solutions, either accepting kind feedback as a learning device, or seeing their feedback implemented into production.

Ultimately, cultures like this will feed upon themselves because happier developers tend to build better tooling, which often everyones’ happiness even more. The culture further perpetuates itself by hiring from within – developers who were ‘raised’ on kind, positive approaches often turn into amazing mentors who do a great job of guiding brand new developers on their way to becoming talented individual contributors.

And mostly, while the purpose of this was not to focus upon developer mental health, or diversity in any way, it’s important to mention that people are usually happier and more comfortable in more diverse environments. And, mental health is an incredibly important topic in development teams, but I’m just not necessarily qualified to speak to it or to write about. But I hope that being nice and supportive can only have a positive impact upon mental health.

Leave a Reply

Your email address will not be published. Required fields are marked *