Developer first
Over the past few years, we have heard several strategies supersede the dispute for how best to approach software development. A few years ago, it was common to use the term API-first. More recently, the enthusiasm was with AI-first. As a developer, I suggest the adoption of a new strategy. A strategy that does not exclude any other one already in progress. One that maintains the same aforementioned suffix, but adds the human factor as radical. Developer-First.
Right now, you might think I want to make developers the centrepiece of software development. If that was your impression, don't worry. You're right. Don't get me wrong, I don't mean that a product should not put customers' needs as the main reason for its development. Note that I used the term software development, not product development, because I consider that customers' needs are already clear at this stage. It is also clear that the solution involves software. The end remains to solve someone's problem. What is suggested here is how to better deal with the means. Software development.
When we realize that software development (still) requires developers, it is evident that the level of developer engagement directly impacts the final result of the software produced. The less are dedication and commitment, the less are the chances of a great outcome. Therefore, it is essential that engagement, usually high at the beginning, does not disappear along the process. So which ingredients would favor developer engagement?
Precision
Software that doesn't work solves no problem. Precision is an unquestioned requirement of any product that is in the market. But maintaining the engagement of those who develop it is also an essential requirement.
If releasing a new feature feels like taking us one step ahead on the game, stoping everything to fix a bug feels like getting us two steps back. Fixing bugs means investing energy just to keep in the same place. If bugs destroy the reputation of software outside the company, they undermine engagement inside it.
Productivity
Developing the most accurate software in the world wins no claps if it never gets shipped. Between a solution draft until the production release, there is the development time. The shorter is this, the faster we can check whether the hypothesis solves a problem or not. And the faster that feedback loop is, the more developers keep engaged with the software they are building.
Another characteristic of flow activities is that they provide immediate feedback. They make it clear how well you are doing. After each move of a game you can tell whether you have improved your position or not.
Turning something on/off at a specific hour of the day or writing similar lines of code for every new feature will get you bored very fast. And when boredom gets in, engagement gets out. Repetitive tasks must be automated as well as every pattern in code must be abstracted.
If it doesn't make sense to launch very fast, something that doesn't work, it's also not viable never to ship something because we're not sure if it works properly. Precision and Productivity are two ingredients that perfectly balance out each other.
Developer-first is an approach that values high developer engagement. And high engagement only happens when we can build very fast, something that works very well.