Published 18 Jul 2019
Writing code is a creative process. Very few employers understand this and it has a hugely negative impact on development projects and developers. Coders are often seen as similar to factory workers, judged on output not quality. Code is seen as a commodity to be purchased at the cheapest price possible. We need to acknowledge that developers are creative workers, and explore what that means for the way we hire and engage with development teams.
So why do I say that coding is creative? We write applications to solve problems. These digital entities may be intangible but they require the developer to conceptualise the problem domain and create a solution that meets its requirements. This exploration of the problem domain is an essentially creative process. There are any number of solutions that will work, but only a small proportion of them will conform to good development patterns and practices, making use of the language constructs and libraries available to create an efficient and maintainable solution. Skilled developers use their expertise to create one of these solutions.
As an analogy consider architecture. I think most people would have no issue with recognising the creative nature of the response to brief when an architect provides a design for a house. The architect must have mastery of engineering principles, so that the house will not fall down, but their design is a unique and creative solution. The same brief provided to a selection of architects will result in completely different solutions from each of them.
If we accept the creative nature of development, the main change we need to make is to treat developers as problem solvers. Normally developers are told what to build, but good developers want to be given the problem instead so that they can exercise their creativity in coming up with a solution. This change might only involve a subtle change of emphasis in how a project is briefed but it is crucial to getting full engagement. As with so many creative activities, the most successful motivation is what Daniel Pink dubbed Type I motivation in his book Drive, where the “I” stands for “intrinsic”:
“Type I behaviour is fuelled more by intrinsic desires than extrinsic ones. It concerns itself less with the external rewards to which an activity leads and more with the inherent satisfaction of the activity itself.”
In his book Pink provides evidence from psychology to show how traditional carrot and stick reward systems fail for most businesses, but are particularly damaging where creativity is required. To avoid stifling creative processes he argues that it is vital to provide a rationale for the task, so that it is meaningful to the individual, and to grant autonomy:
“Allow people to complete the task their own way. Think autonomy, not control. State the outcome you need. But instead of specifying precisely the way to reach it … give them freedom over how they do the job.”
Providing the problem drives this Type I motivation and will result in better solutions and more engaged developers.
Companies can further harness this creativity and improve morale by running hack days. Give your developers some of the business’s problems and see if they can solve them with code. Many organisations do this, and drive significant new opportunities from the outputs.
This engagement is baked into the agile approach which to my mind is one of the key reasons why it is successful. Agile seeks to engage the team in the elucidation of the problem domain through the estimating process at the beginning of the project but also throughout during sprint planning and retrospectives.
Treating developers as creative workers will lead to greater and better quality retention. Our industry has far too many poor developers who are cool with being told what to do, bashing out poor solutions knowing that this makes them appear effective whilst giving them plenty more work down the line as they fix their crufty code. Treat developers like factory workers and the good problem solving developers will get frustrated and leave and you will be left with the losers.
Your hiring process should focus on testing developer creativity, to make sure you get one of the good ones. Give them a problem to solve. Real developers will be willing to put in the effort to work up a solution and walking through it with them can demonstrate the quality of their thinking.
Finally, the reason the factory worker approach persists is because its impacts are not visible to non-technical managers. Everyone can look at a house and appreciate that it is well built and meets the client’s brief but code isn’t like that. We need to change development processes so that code metrics are measurable and visible. This means tracking projects and maintenance properly, so the impacts of more time up front can be demonstrated. This means running peer review processes and collecting scores from them. This means finding code analysis tools that can highlight code quality issues.