Intuitive Developer Environments
Martin Fowler recently started posting my series on Maximizing Developer Effectiveness. Please check the first parts here.
As I expand this series with more articles, I will be getting deeper into the practices that organizations are doing to optimize the feedback loops I mention.
When researching this interesting topic, I found a lot of interesting findings that won’t make into the series. I will use Medium to add additional material.
Micro-Feedback loops and Developer Environments
In the article, I introduce the concept of micro-feedback loops. Which I define as
“The things that developers do 10, 100 or 200 times a day. I call them micro-feedback loops.”
One example of this is deploying a simple personal change and validating it works, the cycle that developers do over and over. The developer has writen some code in an IDE, deploys this to a local developer server, and then checks it see if that what is expected. Or ideally they are using automated tests, so they would run their unit tests to validate it works. This is a key feedback loop, that should be completed in seconds.
Optimizing micro-feedback loops (and a fair amount of yak-shaving) is something I have done throughout the whole of my career. The gains are often through improving the developer environment, by which I mean the environment the developer develops in, where they spend most of their day, this could be a laptop, or it could be a personal cloud environment or a virtual machine.
A development environment that is fast and easy to navigate is essential to be productive. I talked a lot about the importance of being performant in the article, but I wanted to touch on why being intuitive is important
I have spent a lot of time working with ruby-on-rails, one of the great things the creators did is come up with good sensible conventions for common tasks the developer does, commands such as
rake db:migrate or rake server
These conventions make it easy for a developer to learn the CLI for the dev environment, it is intuitive and they aren’t surprised by what happens.
Sometimes when I work with a team, I’ll notice how developers interact with the environment appears to be confusing, you have to run a series of commands in a certain way, or the task does not do what you expect by the name or it, or perhaps there isn’t a common CLI, just a hodgepodge of scripts.
The current team may not see this as a problem, because they have worked with it a long time, and have developed habits around the fastest ways to get the things done they need. They memorize the sequences. I call this “manual automation”. They have effectively automated it as it has become almost unconscious.
The problem comes when the team changes. When someone joins a team with a confusing development environment, it takes the new joinee a significant amount time to become productive. There is a cognitive overhead to learn the intricacies, they probably stumble, make a mistake, feel embarrassed, have to ask for help. Over time they learn the habits the seasoned developers have. This is a cost, a cost on the length of time it takes to become productive.
This cost may be perfectly ok. If your team make up is constant, then it’s maybe not a problem. But this is rare, in the current climate, the one constant is change. As companies perfect their business models, they often have to pivot, re-organize teams or rapidly expand or contract. People also leave unexpectedly; it is a very competitive market for developers at the moment.
The ability to add and change people with little friction is an important capability for tech-first companies. There are a lot more parts to this capacity, such as onboarding process, documentation and mentoring, but a development environment that is simple to pick up and understand is a big accelerator.
Something to think about as you prioritize tech debt to clean up that mountain of scripts!
More about optimizing feedback loops coming up on Medium and in the series on Martin Fowler’s website.