The Reinforcing Nature of Toil

It is is true that toil erodes development velocity and code quality if you have a team of utility players, or if your toil takes up a critical mass of work. However, there are situations where automating toil doesn't increase development velocity:

- You have a developer who is good at manual, repetitive work but has trouble with more creative tasks (toil can keep this person productive as you work to develop their creative potential)

- You have a new developer who needs to learn the system, or your team is inheriting a new project (toil can be a great way to understand the system, its strengths and weaknesses, and possible Chesterton's Fence situations - this is similar to the "don't renovate your house until you've lived in it all four seasons" advice)

- Some toil is unavoidable - our team ingests data from hundreds of websites we don't control. Website operators can change their site content to literally anything, and it's impossible to account for all the issues this can create - even though the fixes can often feel simple and repetitive.

That said, toil is usually unpleasant and feels less impactful, and automating unpleasant work usually has good knock-on effects (happier team members who feel like they're doing impactful work tend to be more productive, stay together longer, and refer their friends).

DORA metrics feed into identifying TOIL:

https://cloud.google.com/blog/products/devops-sre/using-the-...

what's with the assumption that evolution does not include a kind of "code review" meaning some sort of "error" correcting scheme or something??