Doing nothing at work

> Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts.

Not to be sarcastic but just to offer an observation: in a sufficiently large or bureaucratic organization, preventing an incident from happening can rarely get you any credit or visibility. Such achievement falls into the bucket of "what you're supposed to do". So, those who navigate company dynamics well would rather let the incident happen and then be loud on the follow-up action items. The trick is not to turn an incident into a diaster, so it's a dedicate act.

If you want to collapse just run a system at 100% for baseline, there's no slack, there's no capacity to meet new demands, you're just running a permanent failure mode if there's any perturbation in the system.

Tom DeMarco had a whole book about this approach: https://www.penguinrandomhouse.com/books/39276/slack-by-tom-...

The metaphor that changed my perspective came from the book, "The Power of Full Engagement", paraphrasing "you're behaving as if you're a world-class endurance athlete without an off season - stop it."

There's a lot of wisdom in this. In addition to reserving some capacity for when true high-value work comes along, I think software engineering is not the type of job that you can do well if you're constantly busy. Trying to write some code as quickly as possible seldom yields the best design. This article doesn't get into another important aspect of this, which is how to get away with working at 80% capacity without getting in trouble with your manager. This takes a bit of care around communication and estimation of work. One of the first good pieces of advice that I got from older seasoned developers when I started my first real programming job has stayed with me to this day: take your estimate of how long it will take to do something and double it before communicating to your manager/users. As you get more experienced that ratio can come down to maybe 1.5x instead of 2x, but the principle still applies.

It's a good practice to run at 80% utilization and it helps if you are not being managed by people with an overseer mentality, who demand 100% from you all day, everyday. They are the ones who misinterpret the look of software engineers working in relaxed silent repose as lazy idleness. That's why remote work is the best thing to allow me to keep some utilization in reserve and to keep my sanity.

Doing a little bit of "glue work" can make you indispensable and also a hero to your team if it makes everyone's work life a whole lot better and no one else knows how to do it.

I've been "Doing nothing" at work for a couple of weeks now, and it's freaking me out. Yes, I have asked for tasking, but the guy in charge is ... I just don't know.

This goes beyond work. A self made friend told me "if you are always working when will you have time to make money?" We all need free mental space to think.

Thank you for this. I'm new to SWE. How to know when it is time to leave an organization versus sticking it out?

This is written as if you have actual control over the volume of work given to you and/or deadlines.

I've argued the same for 30+ years. Having some slack is healthy so that teams can be simultaneously proactive and reactive to issues. Even the best athletes do not train or compete 24/7.

It sounds like you could have a little "buffer time" where you "do nothing" to prevent burnout when you need that free time for something that pops up and to take adequate breaks to pace yourself cognitively speaking

Otherwise I don't see why you couldn't do lower value tasks with flexibility to abandon them if something higher value comes up

Also applies to research. Keep leeway to open yourself up for collaborations and you might score lots of easy wins even as you struggle with your 'main' project (it also makes you a more well-rounded, sociable scientist)

doing LOTS of nothing can also be a huge power move. i was in software development, technical writing contracting in Silicon Valley back in the 80s. i stepped away to do something completely different for 40 years. curiosity in AI brought me back. the background acquired from my exploration of an apparently unrelated field enabled me to develop some very advanced software concepts relevant to the problems with AI, and implement them in working code.