If you haven’t heard the hype, search “10x Developer” or “10x Engineer” and you’ll find something like:
“an engineer who’s 10 times better at their job than their peers”
You may also come across a 1968 paper, or a recent thread of tweets on the topic. This article isn’t going to waste your time on that topic. However, if you want to find a highly productive software developer/engineer, or you’re looking to become more productive yourself, my tip for you is: focus on continuous optimisation of feedback loops.
Feedback Loops
In the context of software engineering and this article, I define a “feedback loop” as how long it takes to verify that your intended change will work.
Any given change to a software system can have many feedback loops.
Feedback can come from different tools, for example:
- Static Analysis e.g. code linters
- Testing e.g. Unit/Integration/Contract/Acceptance/E2E tests
- Observability (e.g. Monitoring)
And feedback can come from different deployment environments e.g:
- Development e.g. an unique/isolated environment, maybe on your local machine or in a VM somewhere
- Testing e.g. on a CI server
- Staging e.g. a pre-production/common environment shared with a team
- Production i.e. what your customers see
Feedback can be on changes from various parts of a system. For example, you might make a single-line change to a file which affects:
- Application Code e.g. fixing a bug, adding a feature
- Configuration Files e.g. changing a flag or environment variable that gets injected into your application at runtime
- Infrastructure Code e.g. adding a container to an existing Kubernetes pod
- Pipeline Code e.g. changing a build parameter on your CI pipeline
Why Feedback Loops Matter
Once upon a time, I worked on a system with a README that had a statement along the lines of this: “To test these changes work, run X. Now, go and get yourself a coffee and have a chat — by the time you’re done, the answer should be ready for you”.
With that system, I remember it being difficult to push changes out to production multiple times per week — and I want it to be easy to push changes out multiple times per hour!
So why does a feedback loop matter? Because it’s the number one technical lever every engineer has which can shift the dial on their productivity.
The Golden Rule of Software Engineering Productivity
It might seem simple/obvious to some, but here’s my golden rule for quickly shipping software (which applies equally to adding features and fixing bugs/production incidents):
Anytime you can’t make multiple production changes per hour, look for a slow feedback loop. Look at your code, infrastructure, tooling/automation, CI/CD systems, and deployment environments. Then optimise it.
But how much time should you spend optimising it? Pick a target Return on Investment (ROI) and prioritise that level of optimisation. For example, you probably don’t want to spend 3 months shaving 5 minutes off your test suite, but you’ll almost definitely want to spend 1 hour to get that kind of gain. When working in a team, you should also factor in how many people it will impact — there might be a case where a 5 minute saving is worth it!
Ownership Matters
A huge anti-pattern in our industry is that software engineers building products might have colleagues with other titles (e.g. Build/DevOps/Cloud/whatever engineer), and those software engineers have an expectation someone else is responsible for their feedback loops because of their special title. The most productive software engineers I’ve met are ones which take responsibility for their feedback loops, and look to continuously improve and optimise them. Own your feedback loops!
I plan to reference this article in future posts which talk about tools and methods for optimising feedback loops. I’m obviously a huge fan of this practice; I’m largely a fan because prior to formal education I was a self-taught programmer, and I took a trial-and-error approach to learning which was greatly accelerated with every optimisation. That said, I strongly believe in a continuous learning mindset; the best way to learn is by failing — and the best way to know you failed is by getting that feedback!
