Culture is probably the most important aspect of a development team, get the culture wrong and the team and the work will suffer. The question many managers and teams have though is, what culture should we adopt?
To answer this question we need to consider what we wish to achieve, and how we will achieve it. For most sensible organisations they aim to continually push value to their customers. To achieve this they need a cohesive and stable team which work consistently for a long period of time.
There are many negative developer cultures which have gained popularity and don’t align with this goal. Cultures based around the unicorn, rockstar or 10x developer. They are based around the idea all you have to do is hire ‘talent’, provide relevant trinkets and incentives, and apply pressure. Your highly incentivised, superstar developers will then magically produce gold! This of course rarely works, ‘talent’ is difficult to define, a team full of ‘superstars’ isn’t cohesive, and burnout is the most likely outcome.
Wisdom
“A wise person understands the limits of their knowledge.”
A more constructive culture is based around the ‘Humble Developer’. The core principle which underpins this culture is each member of the team accepts the limits of their knowledge.
This is a concept which can trace it’s origins back at least 2,500 years to Socrates and the story of the Oracle of Delphi. In this story the Oracle proclaims Socrates the wisest of all the Greeks. Puzzled by this Socrates decides to validate the statement by questioning the people of Athens about what is truly worthwhile in life. He fails to gain a satisfactory answer, but realises he is the only one willing to admit his ignorance on the subject. This he concludes must mean the Oracle is correct, as only a wise person is willing to admit their ignorance.
A more modern interpretation of this idea comes from the developer Marco Pivetta who claimed in his talk Extremely Defensive PHP, “You are dumb, I am dumb, we are dumb, everyone is dumb.” For one of the most prolific PHP developers on the planet to state they are dumb is quite profound. But again it comes back to the idea that one should know the limits of their knowledge and capabilities. And even for someone with significant knowledge and capability there are limits.
Caution
So how does this translate to software development practices and work? Well first of all a humble developer is cautious, they realise there is a lot of risk involved in what they do and they have limited knowledge. A little like looking out upon a minefield, you are aware it is a minefield, but you can’t be sure where the mines are. So caution is an optimal approach to traverse the minefield.
A cautious developer is aware they won’t get things perfect, and there will be plenty of events which will throw them off course. So they focus on the basics, get the basics right and you won’t go too far wrong. The ‘basics’ of software are difficult to define and developers will never fully agree on them.
But they can probably be broken down into four topics:
- Clean Code: Learn some theory, follow some principles, and run static analysis to keep code consistent, tidy and simple.
- Tests: The more tests you have the more confidence you will have your code will work as expected.
- Security: Nothing is completely secure, but you can ensure run times and dependencies are up to date, and you can run security focused static analysis tools.
- Documentation: Help others understand why your code exists, what it does and how to use it.
None of the above will guarantee you produce great, perfectly designed code, but it does mean the code you produce will be of a reasonable standard and minimise risk. This has significant business benefits as clean and reliable software is much cheaper to maintain.
Knowledge
A humble developer is also aware they will never have complete domain knowledge and they cannot predict the future. So they adopt practices which reveal domain knowledge and can cope with change. This can be referred to as the Behavioral Approach, but is just a placeholder for Lean, Agile, Domain Driven Design, Extreme Programming, and other ideas.
The Behavioral Approach is based around the ideas of complexity and emergence. In complex systems, like a business, new practices and systems emerge from the process of conducting business and interacting with customers. While many still believe there are grand plans that lead to perfect products there never are. Instead successful organisations and teams are those which can respond to customer needs and implement simple solutions to match those needs.
Humble developers realise the first step in the development process is to gain domain knowledge. The only way to deliver value is if you understand the behavior you need to replicate in software. This domain knowledge can be captured in a number of ways, for instance example mapping, and is fundamental to project success. Without it a team is working in the dark and a developer is coding blind.
Humble developers are also open to change, domain knowledge will grow and adapt as a project proceeds so you will need to respond to new information and learnings. This is generally known as ‘Agile’, but all it really means is you work in short cycles, with quick feedback loops so you can respond to change. It also means plans are kept small and achievable, and you avoid hard deadlines with definitive deliverables.
Control
A humble developer is aware they cannot control all the things, control is an illusion, or in some cases a delusion. This concept is particularly important for senior and lead developers. You cannot precisely define and control how individuals or teams will do things, so don’t bother, instead educate and guide.
As David West points out in his book Object Thinking the route to better software is better developers. Or in other words better educated developers. Education aims to increase understanding so others see the value of certain methodologies and practices. If a team isn’t writing tests don’t just tell them to write some tests or achieve an arbitrary coverage score. Instead organise training sessions to educate the team on the value of tests. Or pair programme problems with developers where you test first so they can learn the benefits.
Guide rather than tell, set achievable goals, but don’t tell people precisely how to do things. Don’t delude yourself that you fully understand a problem or there is only one solution. If you want to increase code quality and observability you might ask developers to add badges to their repos which communicate and prove the quality of their code. But don’t tell them precisely which tools to use or metrics to display. Provide space for developers and teams to explore problems and let solutions emerge.
Teamwork
A humble developer is aware they cannot solve all the problems alone. They ask for help with problems and they are open to helping others. They work on their communication skills because they know this will help them engage team mates and solve problems faster.They are open to diverse opinions which can only be accessed when when working with a diverse array of people.
Teamwork has huge benefits, it increases productivity, improves wellbeing, and reduces stress and burnout. The Humble developer recognises these facts and leans into teamwork to achieve better outcomes.
Final Thoughts
A humble developer is wise rather than arrogant, cautious rather than reckless and a team player rather than a lone wolf. As a manager if you encourage a culture of humble developers you will produce more affective and cohesive teams. Teams which will pull together, solve problems faster and deliver business value.