Determining what types of engineering work the robots should handle and what should be left to the humans is simple.
Let AI and automation do all the stuff that creates toil for engineers, and let engineers handle the real work.
But of course, it’s not that simple. The reality is that even though automation and AI can take on time-saving work for developers, they still require human involvement. Humans need to know the why behind what they’re asking the robots to do, so that they know when the robots get it wrong — and how to make it right.
AI vs. Automation
It goes without saying that AI gets a lot of air time these days. With its algorithmic ability to learn over time, perform complex tasks, and even make decisions, its impact on saving time for developers can be significant.
As a simple example, I recently used AI for some boilerplate billing code that uses Stripe. I had a specific task to complete, and the AI assistant suggested 14 lines of code to accomplish that task. When I went through the code, however, it didn’t all align with our processes, so I modified it.
Having that initial code certainly gave me a leg up and allowed me to get into and stay in the flow, but I did need to know what I wanted to do with that code and know when the boilerplate was wrong.
This is another iteration on the point that regardless of the type of robot, humans still need to be involved in software development work that we’re asking them to complete.
Personally, I see greater capabilities specifically for the purpose of reducing toil for developers with automation — rule-based software that follows a set of constraints to work within. It often has the goal of eliminating repetitive tasks that eat up developers’ time, but it also can help improve team culture and processes.
Automations take efficiency to new levels
So how do humans implement automations? They can be built to solve a variety of circumstances and therefore have the potential to eliminate many repetitive and manual tasks (aka, toil) that waste developers’ time — and improve teams’ efficiency in the process. (And, automating away more and more toil is one way the software industry constantly moves itself forward.)
You can think of automations in four main categories.
- Guardrails: Automations that ensure agreed upon boundaries for teams to work within are codified into processes.
- Notifications: Automations that ensure user awareness of conditions that might require their attention, so they don’t have to proactively detect such conditions themselves.
- Actions: Automations that execute complex actions.
- Workflows: Multiple automations that together form a new capability to achieve advanced developer workflows.
Take guardrails, for example. Teams can put a guardrail in place that automatically checks for an issue key in commit messages that they make in their repository. If it’s missing, the guardrail forces developers to add the information. This allows anyone to link off to that issue, read it, and understand the context behind it without having to dig into the issue. You’ll notice the human component involved in that automation. But thanks to the automation, developers can get the information they need more quickly. Efficiency gained.
Or, consider automated actions, which follow “if this, then that” principles. If a certain condition or state is detected, an automatic action is taken that typically leads to a change in the state of a system. It can mean adding a comment to an issue, transitioning an issue from one state to another, or modifying a pull request by adding a label, merging it, or closing it.
It goes without saying that humans traditionally handled these tasks. But the advent of automation allows us to offload them to systems that can perform them more consistently and quickly, reducing developer toil.
Even with the time-saving and toil-preventing role of automation, humans can and might need to override the system. There could be times when it’s okay to ignore automatic modifications, for example, but the only way to know that is to have a human involved. Robots won’t know all the exceptions to the rules.
The potential in reducing toil
What do we as an industry gain from reducing developer toil? Automation frees developers to do their best work, and the benefits snowball from there.
– Developers have the headspace to solve problems creatively, improve and optimize things, and get into their coveted “flow.”
– Developers who get to spend more time on work that’s challenging and interesting are more likely to avoid burnout.
– Developers who avoid burnout and like their work stay in their jobs.
– Developers who stay in their jobs save companies time and money.
– Companies that use their resources effectively alongside happy developers pass on value to their customers.
– Happy customers give developers the signal that their work matters.
And let us not forget that removing toil frees up the time to identify more toil. Every time you remove a bottleneck, you uncover a new one. And even if that bottleneck is much less impactful, it’s still a constraining factor. So, the more things you remove, the more time and ability you have to identify the next layer deep to improve.
That’s part of the job of engineering — investing in a culture of continuous improvement where you’re always working smarter, not harder. And that’s going to require automation and humans working together.
About the Author
Dylan Etkin is CEO and co-founder of Sleuth, the leading deployment-based metrics tracker. As one of the first 20 employees at Atlassian, Dylan was a founding engineer and the first architect of Jira. He has led engineering for products at scale in Bitbucket and Statuspage. He has a master’s degree in computer science from ASU.
