How to lose your developers
This post is randoms thoughts around software development from a developer point of view. 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 developers, soft skills, hard skills and management.
On top of that, I was inspired by the book Mind Map Mastery from Tony Buzan  and also by The software craftsman: professionalism, Pragmatism, Pride by Sandro Mancuso , 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 it. The “standard” is to have a computer science (or any related subject) degree and then start working on for a company.
Usually the shift from study only mode to working mode brings more things responsibilities. For example, dealing with deadlines, struggling with bugs, writing documentation, talking with business and trying out new technologies (just to name a few).
it is easy
The first way to start a fight in the middle of a meeting with developers is to say the phrase: “its easy”. It is a bonus point if followed by “it’s just a button”. This impactful phrase can be taken as 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 started for the developer to lose confidence and start to search for another job.
Lack of documentation
Since the agile manifesto documentation has been a subject of a second matter. Even though, being a secondary subject doesn’t mean to not have it. Teams struggle with outdated documentation (when it exists). I personally think that people misinterpreted the manifesto and uses 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.
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 actually write the code is the last of a chain that starts with the problem to solve.
Building software is not an assembly line, that each stage is well-defined and workers have to do simple moves to accomplish a task. Building software is a solving 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 in 1?
This dialog is weird, as you that have no idea is 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 or business start to pressure for sooner deliveries.
Don’t worry we will test it later
Developers deliver value through tasks, be it in a staging environment or in production, the final word should be from the users, or the ones that are responsible for the feature. It also applies for bug fixes, the one who wrote the bug ticket, should be the one to double-check it and give a positive feedback.
There is a long journey to fix something or implement something. It requires communication both with the business and also code wise, then understanding the code that is in place, modifying it and often, add 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.
Let’s say that all the steps have been finished up 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 confirm that. This loop should be as short as possible, and not testing it right after it was delivered leads to:
- Lack of confidence with the team
Longer feedback circles can also lead to the feature or bug to be reworked and change too may time, as the cycle is long, often it is difficult to keep track of all the changes and make decisions.
Tackling the engineering culture
Pack Kua, in his talk  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 is the distinction between the enterprise scenario and the startup, on his talk those are totally different things and he uses that to contrast those two worlds.
- T. Buzan, Mind map mastery: The complete guide to learning and using the most powerful thinking tool in the universe. Watkins Media Limited, 2018.
- S. Mancuso, The software craftsman: professionalism, Pragmatism, Pride. Pearson Education, 2014.
- 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]
Table of contents
- The well known path
- Tackling the engineering culture