One of the key elements of an efficient working environment for a developer is feedback loops which are as short as possible. When I was writing code daily, I invested what I thought was a fanatical amount of time and effort in reducing the overhead of every dev-related cycle.
Checking out, writing code, compiling, stepping through, altering code, spinning up remote resources, rebooting web servers, restoring test databases, checking in – everything was automated and stripped down to the shortest possible cycle time.
Then I started working with some other very senior developers – and really learned the meaning of fanatical. Macros, keyboard mappings, shelling out to scripts… they took the art to a whole new level. Seeking out short feedback loops is instinctive for developers. It is fundamental to our productivity and helps keep us in the zone.
You can often distinguish a good developer from an average one, by what they do when they encounter long feedback loops. Average developers climb on chairs and start sword-fighting. Good ones are working on the build script, so they don’t have to wait so long next time. They are fundamentally motivated by the results of that loop and it is simply instinctive to reduce the time it takes for those results to be returned, in any way possible.
The bad news: Nothing you do in management will have a short feedback loop – at least not in terms of time frames you are used to. Development loops range from sub-second up to minutes at the very most. For management decision-making, the range runs from hours to never – and it’s almost always never. Because a corollary to long feedback loops in management is that you will also never, ever be sure that a decision you made actually caused the outcome you observed later. Developers drink directly from the bottle of job satisfaction when it comes to identifying, working on and fixing problems. Managers are left sucking the dregs out of the carpet. A week later.
The fix: You quite simply have to let go of this one. You need to focus on acting through others and thinking in the long term. If you find yourself thinking “it would just be quicker to do it myself”, stop. It may be quicker this time, but what about next time? And the time after that? Working through others means you have to build knowledge, skills and understanding in your team, even if it pains you to watch it first time around.
Perversely, you also need to drop your standards. Your team will have a variety of skill levels within it and sometimes the junior dev won’t write code to the standard you would have yourself. Participate in code reviews, provide feedback and concentrate on the team, rather than the task.