In a times software eats the world it is important to improve the developer productivity, improving the developer experience, which leads to a better organization productivity, faster reaction to the market, increasing profit.
Tim Cochran, from Thoughworks, writes an interesting article about developer effectiveness with some interesting quotes (emphasis mine):
“When we look into these scenarios, a primary reason for the problems is that the engineering organization has neglected to provide developers with an effective working environment. While transforming, they have introduced too many new processes, too many new tools and new technologies, which has led to increased complexity and added friction in their everyday tasks.”
We seems to know what is the correct environment for developers to improve their effectiveness (from the article as well).
Day in the life in a highly effective environment #
The developer:
- checks the team project management tool and then attends standup where she is clear about what she has to work on.
- notes that the development environment has been automatically updated with libraries matching development and production, and the CI/CD pipelines are green.
- pulls down the latest code, makes an incremental code change that is quickly validated by deploying to a local environment and by running unit tests.
- depends on another team’s business capabilities for her feature. She is able to find documentation and the API spec through a developer portal. She still has some queries, so she jumps into the team’s Slack room and quickly gets some help from another developer who is doing support.
- focuses on her task for a few hours without any interruptions.
- takes a break, gets coffee, takes a walk, plays some ping pong with colleagues.
- commits the code change, which then passes through a number of automated checks before being deployed to production. Releases the change gradually to users in production, while monitoring business and operational metrics.
However, what I see from my experience is organisation management trying to control everything, taking out autonomy and leading to the following (from the article as well):
Day in the life in a low effective environment #
The developer:
- starts the day having to deal immediately with a number of alerts for problems in production.
- checks a number of logging and monitoring systems to find the error report as there are no aggregated logs across systems.
- works with operations on the phone and determines that the alerts are false positives.
- has to wait for a response from architecture, security and governance groups for a previous feature she had completed.
- has a day broken up with many meetings, many of which are status meetings
- notes that a previous feature has been approved by reviewers, she moves it into another branch that kicks off a long nightly E2E test suite that is almost always red, managed by a siloed QA team.
- depends on another team's API, but she cannot find current documentation. So instead she talks to a project manager on the other team, trying to get a query. The ticket to find an answer will take a few days, so this is blocking her current task.
“We could go on. But ultimately the developer doesn’t achieve much, leaves frustrated and unmotivated"
“In the example illustrating a low effective environment, everything takes longer than it should. As a developer, your day is made up of endless blockers and bureaucracy. It is not just one thing; it is many"
“Slowly, productivity is destroyed by small inefficiencies, which have compounding effects. The feeling of inefficiency spreads throughout the organization beyond just engineering. Engineers end up feeling helpless; they are unproductive. And worse they accept it, the way of working becomes an accepted routine defining how development is done. "
Published