This reminds of a situation I faced early in my career. We worked on a network alarm management tool, and some of us used to rewrite the tool or bulk of its features. To a point we finally arrived to invent our own tools to fill up the gaps in the feature set offered by the current tool.

It used to be one of the biggest reasons why we learned so many thing in comparison to the rest of the team(which was fairly big), to a point we could make a lot of very critical design decisions or write an application that could save hours of time for our users.

Its one of those axioms of software development I've learned, in order to do good work you have to do mountains worth of waste work.

> Its one of those axioms of software development I've learned, in order to do good work you have to do mountains worth of waste work.

It suggests an obvious question though: can we do better? Can we avoid having to do "mountains worth of waste work" before getting to do the "good work", or is the former a necessary prerequisite for the latter?

I believe we can reduce the amount of waste work by doing deliberate practice.

This means really analysing what you did and how it could be better.

Also doing a small amount of work each day is much better than a large amount once a week.

Take a large task and break it down into tiny manageable chunks that you can analyse.

There's tons of material out there that has best practices for mastering anything.

It's not just about skills, but also about knowing what problems to solve and being in the position to solve them. I wonder if we can side-step having to do waste work in the latter cases.