Often very useful things are never the "next most important" if you don't scope "importance" very carefully.

"Slow down to speed up" can capture it, setting aside times for those non-critical maintenance steps that prevent problems or make everything just a little bit faster can make worlds of difference in your work, but never seem to be able to compete with the "next most important" thing on the list.

That reminds me of the military saying "slow is smooth, smooth is fast".

I like that analogy a lot! I've just realised that the same thing applies to racing, for example. The way I tend to play racing simulators is that I try to go full throttle all the time, and then when I stumble upon sharp turns, I just crash into them, losing much more time than I would if I didn't try to go as fast as I can all the time.

This is actually a thing in real racing, the fastest times through complex curves look slow.

I think the “doing your work well” part is often the question. Am I really doing all I can? Could I do better/more? This then leads to working more and being busier. Maybe the problem is that it’s hard (for some of us) to know what “well” really means.

I think "Could I do better/more?" is just a dumb question. As an employee, I have no plans to ever ask that of myself again. I'll get some things done that I set out to do, sometimes they'll take more or less time than I think, and the rest is either neutral or margin. There's no point in doing more. But you're right, you need a measure of what the right amount is, and I think that varies and can be hard to pin down.

This comment reminded me of this from the recent post of Sivers' Relax article.

In a marathon-like environment, you don't want to go to 100% for a very long time, because you'll drop to 50% or less for a longer time than maintaining at 85% for the majority of the event.

You can always do more, so the question then is: Do you really need to be doing more right now? Is this the best use of the boost before I need a break?

https://news.ycombinator.com/item?id=32626119 sive.rs/relax

This is one reason why I go all in on practices that are backed by data to correlate with business success (CI/CD, DevOps, etc.). Think the Accelerate book. Software development has the added difficulty of being quite a young industry (relatively speaking), but (with tongue in cheek) how can you be expected to do better than practices espoused by industry leading research and companies?

Thanks, that sounds like a good strategy. I’ll have a look at the Accelerate book.

> how can you be expected to do better than practices espoused by industry leading research and companies? True, but not everyone has reasonable expectations :-) In those cases perhaps all that remains is to either have a frank discussion or to part ways.

Like I tell my kids when they go too fast (I heard it from somewhere)...

   "Smooth is fast kids, smooth is fast!"

Originally it was: "slow is smooth, smooth is fast"

and speed is economy of motion