Doing nothing at work

Join the discussion

• Hacker News
• 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.

  by codewarrior2000
• 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."
  by garrickvanburen
• 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.
  by hilariously
• I’ve had a half-written blog post in this vein for a while now using a fantasy RPG analogy: if you play a character that uses mana in any of these games, you’ll learn fairly quickly that using it all up all the time on trivial battles and running around empty leaves you with none when you genuinely need it.

  Your mental energy deployed at work is not so dissimilar: keeping some in the tank gives you the option to deploy it strategically, rather than risking your health (burnout) when something unexpected comes up.

  If you join a group in one of these games with a player who is bad at managing their mana, you’ll also find that they’re not such great teammates, either.

  by macNchz
• 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.
  by o_nate
• > 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.

  by hintymad
• > I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or willingness to ensure that work is formally recorded under your name. For instance, a product manager from another organization messaging you to say “you’re so good at querying data, would you mind pulling some statistics for me about X?”, or an engineer from another team asking you to “pair” on a piece of work that will ultimately involve you writing all the code and them quietly submitting the change under their own name.

  Put this in a frame.

  by wiseowise
• This is a good post, but once again incentives rear their ugly head.

  > 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.

  Time and time again at many companies, including well-reputed ones, I have seen that preventing issues gets you no recognition, but building a giant pile of kindling and then putting out the inevitable fire will get you recognition twice. Even in "good" orgs.

  I've never been able to commit to the game theory politics enough to intentionally ship garbage fast and take that credit - I take too much pride in my work - but I have spent 5+ years managing and growing a framework designed to eliminate classes of issues that plagued the last version of our product and watched as partner teams who ship garbage code and cause outages get public credit for fixing those outages and my team, despite attempting to advocate, get no credit for not having such outages because you can't measure that.

  by Arainach