Many studies have revealed a strong correlation between productivity and developers’ happiness (see Chapter 10 of this book for multiple references). Despite this, in my experience many companies do not prioritize key initiatives that go in this direction. To expand on this idea, I want to explore some of the things related to developers’ satisfaction that are sometimes underestimated and downplayed.
Disclaimer: These are just my opinions, based on my own experience. Some sentences might sound too categorical or like an unquestionable truth, which is far from the reality. There are always trade-offs, limited resources and particular problems to be solved, that would require a lot of “depending on”, “except ifs” that I will avoid for the sake of clarity and conciseness.
Focus on developers
Making developers’ lives easier should be one of the top concerns for engineering organizations. What the majority of developers enjoy the most is building stuff, solving problems and getting things done. Anything we can do to maximize the time developers spend doing what they enjoy will have a great impact on productivity. These are some examples of actions that can be taken to make developers’ lives easier.
Automated deployments
This one is a no-brainer to me. There is a lot written about the benefits of CI/CD or any automation that improves the deployment experience. The 2018 StackOverflow Surveyrevealed that the most satisfied respondents were the ones that shipped code multiple times per day. You need incentives for developers to do this. Running tests when a Pull Request is created, and deploying the code automatically when the changes are merged are ways to encourage shipping.
Faster Tests
Losing focus and context switching are some of programmers’ worst enemies. Fast tests allow for immediate feedback, which is key to maintain the flow state where programmers peak their performance. In this study, researchers found that after most of the interruptions programmers took 15 minutes or more to start editing code again. This insightful talk expands on the topic of fast acceptance tests.
Friendly development environment
Being able to run the software seamlessly in your development environment is vital to avoid unnecessary frustrations to programmers. It is not only about being able to run the software successfully, but about removing any overhead required to switch between projects, configuration files or secret keys that have to be edited, commands that need to be run, etc. When possible, enable hot reloading for all components in your application, i.e. when programmers change the code, the app should apply those changes automatically, without any manual human interaction.
When a new tech component such as a new database or a new architectural pattern is introduced to solve a problem, we not only have to make it work and be able to test it, we also have to think how will developers run it in their development environments without further efforts or requiring extra context.
Small improvements in the Developer Experience can have a great impact on how programmers feel when they are implementing new features.
Boring Software
I believe boring software is one of the most underrated concepts in modern development. We follow trends sometimes blindly resulting in the hype cycle below:
We should avoid adopting technologies or architectural patterns at the Peak of Inflated Expectations. Identifying where a technology stands in this curve would need another post, but as rule of thumb, given that we all know that everything has trade-offs, if you can only find talks, podcasts and articles describing why you should adopt the technology, and why it is great for this and that, and you cannot find anything describing when this might not be a good idea, some examples where the technology failed to solve the problem or introduced bigger problems, it is probably too hyped and there is not enough information to make a well-founded decision.
There are cases where it is clear that the new “cool” technology will solve the problem we want to solve, no doubt about it. Even then, there might be still strong arguments not to adopt it.
At Intercom, we apply our “Run less software” filosophy when we evaluate these decisions. The velocity benefits must outweigh the operational cost of introducing a new technology to your stack. Being the best tool to solve the problem is not a good enough reason to introduce a new tool. The areas affected go beyond that: maintainment, testing, working with it in the development environment, recovering from failures, training people to use it, etc. Taking everything into account, the best option may be to solve the problem with the already adopted tools, where all those points are already solved and there is a greater grade of expertise in the team. This blog post expands on this idea.
Tenure
Programmers stay in their jobs for a median of about 2 years, depending on the size of the company. The cost of engineering turnover is high; it not only incurs in direct costs as a result of the time invested in exit interviews, management meetings, handover processes, finding and interviewing candidates, etc. But there are also hidden costs as a result of the inevitable loss of productivity, adjusting deadlines, onboarding a new hire and getting them up to speed. Not to mention the shortage of developers nowadays, making it harder and more costly to replace employees who left the company.
What can we do about it?
Gallup states that “managers account for at least 70% of the variance in employee engagement scores”.
“Employees join companies but leave managers”
Even if this catchy line has been slightly contested by this study at Culture Amp, I think the idea still stands: The conclusion is that employees leave leaders.
There are a lot of factors that make someone a great manager, but I want to mention one that is particularly important from the individual contributor perspective. I would dare to say this manager behavior is also underestimated (or maybe I just value it too much): Caring about people.
At Intercom, we do not have a limit on the number of days off that we can take, at the discretion of the manager to approve them, of course. To be honest, I was afraid this would be the classic trap where, in the end, employees take less days off than what they would if there was a limit. I can tell I have been directly asked (almost forced) to take more days off in my one-on-one meetings with my Engineering Manager (EM). I have been pleasantly surprised to see our EM encouraging the same in team meetings and the CEO in All-hands meetings. References to taking care of ourselves and our loved ones are a constant, and my EM has been really supportive when moving homes. With that in mind, any disagreement can be looked at with a more positive perspective, where it is easier to assume good intentions.
Caring about people is not only about how they feel and the personal aspect of the relationship. Creating the space to talk about what is frustrating about the daily job or what went wrong in the last project is also key to maximize developers engagement, which leads me to one of the vital points to fight against turnover in my opinion:
“Listen to developers”
This apparently shallow, life coach kind of sentence hides a strong truth. You need to know what is frustrating to developers. It could be that the last architectural pattern introduced, that requires them to write a lot of boilerplate, and takes them twice as long to ship features is creating burnout programmers. If this is the case, maybe it is time to re-evaluate the need of that addition, or put resources to make it more friendly for programmers.
To have access to such invaluable information, there has to be spaces and channels to share feedback. It is not enough to just encourage everybody to share feedback any time there is something not working perfectly. The organization must provide friendly ways to gather feedback. Some of the formats I have seen working efficiently are:
Surveys: Provide a way to ask about engagement to all employees in a format that can be quantified, compared across groups and over time.
Retros: To evaluate the way a team works or what went wrong and/or well in the last project.
One-on-ones: A good way for ·Engineering Managers to get qualitative feedback in a private conversation. This can help find patterns like the ones mentioned above, where developers may share some concerns.
Incident reviews: After an incident happens, a review is conducted to share lessons learned and agree on action points to avoid future incidents with the same root cause.
In summary, these are just some ways to help developers do their job without unnecessary frustrations.