The title is a bit misleading. The author is advocating getting rid of dirty work by solving the problem. This can mean starting by doing the dirty work, i.e o

The title is a bit misleading. The author is advocating getting rid of dirty work by solving the problem. This can mean starting by doing the dirty work, i.e on call to identify the problems. Fixing them is what he is advising people build their careers on. This is definitely something I have advocated for, and recommended to other people. I'll add that a lot of the work that is referenced here is good at 80% done and only marginally better until it takes a giant jump at 100%. Code coverage is a good example of this, getting from 0 to 80% code coverage is good. Getting to 95% code coverage is slightly more useful. Getting to 100% gives you leverage to find dead code, have actual confidence is things, prevent new features and code from not being tested (previous person go to 95% coverage, so a new feature might not dip the gate), and removes a lot of arguments around "I'll add tests later". I've seen similar patterns with things like on call incident queues for hitting 0 incidents. And automated alerts becoming so reliable that engineers don't dismiss them as noise etc.