How to lose your developers - Mindmap around software development, what not to do to lose developers

The content here is under the Attribution 4.0 International (CC BY 4.0) license

This post is random thoughts about software development from a developer’s point of view (strong opinions on the way!). The content covered is mainly based on my career, and the opinions expressed might not fit all scenarios. Do not take the text as a saint grail or a tutorial, it is more like a conversation on what I think about software development, soft skills, hard skills and management.

On top of that, I was inspired by the book Mind Map Mastery by Tony Buzan [1] and also by The software craftsman: professionalism, Pragmatism, Pride by Sandro Mancuso [2], which I share the same opinions as he expressed in the book.

The depicted mind map above is the result of my dive into mind mapping, the subject approach is what this post came to be.

The well-known path

Developers usually start picking up a programming language and playing around with it. The “standard” is to have a computer science (or any related) degree and then start working for a company. Usually, the shift from study-only mode to working mode brings more responsibilities. For example, dealing with deadlines, struggling with bugs, writing documentation, talking with businesses and trying out new technologies, building prototypes, research, etc (just to name a few).

it is easy

The first way to start a not fruitful discussion in the middle of a meeting with developers is to say the phrase: “it’s easy”. It is a bonus point if followed by “it’s just a button”. This phrase of impact can be taken as a two-sided coin, if it comes from another developer, it will be more likely to be accepted, therefore, if it comes from a business or someone that is not part of the daily coding task of developers, it can be interpreted as an “insult”.

I see no problem with those phrases, but, in a given context where developers are working under pressure, having to deal with meetings, support for clients and many other tasks besides coding, it can be a starter for the developer to lose confidence and start the search for another job.

If we were to do a comparison, would we go to the dentist and say that we are “easy” to treat?

Lack of documentation

Since the agile manifesto documentation has been a subject of a second matter. Even though, being secondary doesn’t mean not having it. Teams struggle with outdated documentation (when it exists). I think that people misinterpreted the manifesto and used that as a shield to jump the documentation step. To achieve technical excellence, documentation is needed, as it can be used as a way to share knowledge among the team. The following list enumerates the benefits of having documentation:

1. Reinforcing what has been done
2. Share what has been done across the team
3. Allows improvement, as it is written, it can be analyzed and improved.

The “down” side is to keep it up to date. Documentation should be a commitment to avoid such situations.

You have until Friday to finish up

Imposing deadlines on developers can lead to friction. Developers are not a “code machine”, writing code takes time, creation and problem-solving. Sometimes the step to write the code is the last of a chain that starts with the problem to solve.

Building software is not an assembly line, each stage is well-defined and workers have to do simple moves to accomplish a task. Building software is a problem and creative process.

Imposing deadlines on developers uncovers illness under the hood of the team or even the organization. Imagine you going to your dentist and having the following conversation:

• Dentist: it will take 2 days to finish up your treatment.
• You: 2 days? I can’t wait, can you do it in 1?

This dialog is weird, as you who have no idea are trying to impose how long the dentist’s work is going to take. Did you find this weird? This is the feeling that developers have when managers start to pressure for sooner deliveries. I would also classify this as a piece of micromanagement. As the HBR article states:

Engineers hate being micromanaged on the technical side but love being closely managed on the career side.

Don’t worry we will test it later

Developers deliver value through tasks, be it in a staging environment or production, the final word should be from the users, or the ones that are responsible for the feature. It also applies to bug fixes, the one who wrote the bug ticket, should be the one to double-check it and give positive feedback.

There is a long journey to fix something or implement a new feature. It requires communication both with the business and also code-wise, then understanding the code that is in place, modifying it and often, adding something on top of it.

It gets worse when the code base is not focused on technical excellence, thus, making the previous steps even harder. [3] Highlights the importance of such technical skills to deliver as fast as possible to the business and increase its competitive speed against competitors.

Let’s say that all the steps have been finished and the bug or feature has been deployed to staging, on the developer side, it is a lot of expectation because it is the time when the user will see the change and have the chance to play with it. This loop should be as short as possible, and not testing and practicing tests continuously, can potentially lead to:

• Frustration
• Lack of confidence in the team

Longer feedback circles can also lead to the feature or bug being reworked and changed too many times, as the cycle is long, and often it is difficult to keep track of all the changes and make decisions. Gerard Meszaros in his book also quotes project managers as being one of the root causes of such behavior:

It can be hard enough to get project managers to buy into letting developers write automated tests. It is crucial that we don’t squander this opportunity by being sloppy or inefficient. The need for this balancing act is, in a nutshell, why I started writing this book: to help developers succeed and avoid giving the pessimistic project manager an excuse for calling a halt to automated unit testing.

xUnit Test Patterns - Refactoring Test Code, 2007, pg 14

Tackling the engineering culture

Pack Kua, in his talk [4] enumerates a few ideas that I would like to share here as they are engineering-oriented. Those ideas are based on his experience working across different projects and companies.

The part I enjoyed the most was the distinction between the enterprise scenario and the startup, In his talk, those are different things and he uses that to contrast those two worlds. More recently I came across an article entitled “How to Spread Technical Practices Like TDD in an Organization” by Emilie Bache and one of the key takeaways from the text is shown early on in the article:

One of the success factors for Agile and DevOps is developers changing the way they work and adopting practices like Test-Driven Development (TDD). It’s not something that just happens by itself, and many of the “usual” ways of introducing change fail for TDD. In this article I will outline some of the things I’ve tried that actually do work. I’ll explain “Samman,” which is the coaching method I use with developers.

How to Spread Technical Practices Like TDD in an Organization, Emily Bache 2021

So technical excellence will not come with a magic scrum master, or the shiny new certification from the project manager, this should be the core of the engineering team in any organization. Being agile is not possible if you lack this principle.

References

1. [1]T. Buzan, Mind map mastery: The complete guide to learning and using the most powerful thinking tool in the universe. Watkins Media Limited, 2018.
2. [2]S. Mancuso, The software craftsman: professionalism, Pragmatism, Pride. Pearson Education, 2014.
3. [3]N. Forsgren, J. Humble, and G. Kim, Accelerate—building and scaling high performing technology organizations (The science of lean software and DevOps). IT Revolution Press Portland, 2018.
4. [4]P. Kua, “Secrets of a Strong Engineering Culture,” 2020 [Online]. Available at: https://www.youtube.com/watch?v=bGNfKEKnEbk&t=723s. [Accessed: 11-Apr-2021]