HN Debrief

Doing nothing at work

  • Programming
  • Management
  • Careers
  • Infrastructure

The post says “doing nothing” at work is often just keeping capacity in reserve. In software teams, that slack gets spent on the work that keeps systems and people healthy: jumping on incidents, thinking through design before coding, handling interruptions, and doing small but useful coordination work that unblocks others. The author’s point is not laziness. It is that engineers who stay maxed out have no room for surprises, and systems run the same way. Several commenters tied this directly to classic operations thinking. A team at 100 percent utilization is already in failure mode. The same logic applies to human attention, where constant load turns every surprise into a crisis and pushes people toward burnout.

If you lead engineering, treat unused capacity as operating margin, not waste, and make preventive work and glue work legible in reviews. If you are an IC, protect slack with explicit tracking, better estimation, and boundaries around uncredited requests, because many orgs will otherwise consume every spare hour.

Discussion mood

Strong agreement with the core idea that engineers and teams need slack, mixed with cynicism about whether most companies reward it. The mood was shaped by burnout stories, complaints that prevention is invisible while heroics get praise, and practical advice about protecting time with estimates, tickets, and boundary-setting.

Key insights

  1. 01

    Prevention loses to visible heroics

    Preventive engineering often fails the career scoreboard because the win is the absence of pain. Frameworks that eliminate outage classes, presubmit checks that block bad configs, and quieter on-call rotations can save real money, yet they produce no dramatic story for management. The team that causes the incident and then scrambles to restore service gets a memorable narrative and public credit. That changes how you should read the post. Slack is useful, but without a recognition system for avoided incidents, the org can still reward the exact opposite behavior.

    If you manage engineers, add concrete prevention signals to reviews and planning, such as page volume, classes of bugs eliminated, and blocked risky changes. If you are an IC, keep your own evidence trail for avoided incidents because the organization usually will not assemble it for you.

      Attribution:
    • Arainach #1 #2
    • JohnMakin #1
  2. 02

    Tickets are protection, not bureaucracy

    Formalizing side requests was framed as the difference between healthy collaboration and invisible labor. Small favors can absolutely help the company, and you will want that reciprocity later, but once work arrives through backchannels it becomes easy for priority to drift and credit to disappear. A ticket or some lightweight tracker keeps the ask visible, lets you place it in the queue, and gives you a record when review season arrives. That makes “be helpful” compatible with “do not get quietly loaded up with everyone else’s leftovers.”

    Set a default rule that any request above a quick answer needs a tracked artifact. Use that record to negotiate priority and to make cross-team support show up in status updates and reviews.

      Attribution:
    • moduspol #1
    • m463 #1
    • Arainach #1
    • ranger207 #1
  3. 03

    Glue work works when everyone owns it

    The best pushback to the post was not that glue work is fake, but that it only becomes exploitative when it is informal and unevenly distributed. One commenter described a large company where “citizenship” was an explicit review category covering work like documentation, interviewing, and organizing team activities. Making it part of everyone’s job prevented the classic pattern where high-status engineers dodge coordination work and lower-status people, often women, carry it unrewarded. That reframes the article’s warning. The problem is not glue work itself. The problem is pretending it is optional while the organization quietly depends on it.

    If your team relies on onboarding, docs, interviewing, and coordination, put those tasks into formal expectations and rotate them deliberately. If you do not, the work will still happen, just with worse fairness and worse incentives.

      Attribution:
    • zem #1
  4. 04

    Slack comes from expectations management

    Several commenters made the practical point the article skipped. Reserve capacity does not appear by magic. Engineers create it through estimation, communication, and trust. That means committing to less than nominal capacity, leaving room for interruptions, and building a track record of hitting the promises you do make. The useful frame here is not sandbagging for its own sake. It is setting predictable delivery as the product, because predictability buys the autonomy to think, respond, and avoid burnout.

    Treat estimation as capacity planning, not optimism with a date attached. Under-commit consistently enough that stakeholders learn your dates are real, then spend the margin on interruptions, design, and maintenance instead of panic.

      Attribution:
    • o_nate #1
    • martin-uk- #1
    • qazxcvbnmlp #1
    • gorjusborg #1
  5. 05

    Idle periods are career risk if wasted

    Not everyone read “doing nothing” as welcome breathing room. A few people described being unassigned for weeks and watching their skills decay or their project drift into funding limbo. The more useful interpretation was that slack should be spent intentionally on maintenance, tooling, documentation, bug fixing, or learning adjacent tools you already use. Otherwise the same empty calendar that feels restful at first can become stagnation with no story to tell later.

    When assigned work dries up, create a visible backlog of cleanup and learning tasks before drift sets in. If you cannot find meaningful work for long, treat that as a signal to plan your next move.

      Attribution:
    • black3r #1
    • hiq #1
    • gib444 #1

Against the grain

  1. 01

    Rigid channeling can cripple responsiveness

    Insisting every request go through the full official path can turn sensible boundaries into organizational drag. In places with heavy process, waiting for budget codes, staffing updates, or formal assignment can delay useful work for weeks when a quick intervention would solve the problem now. That does not invalidate the need for tracking. It does warn that a blanket “not my job, file a ticket” culture can create the same kind of waste the post is trying to avoid.

    Keep the tracking lightweight enough that urgent or obviously valuable work can start quickly. If your intake process takes longer than the task itself, fix the process rather than forcing people to work around it.

      Attribution:
    • bumby #1 #2
  2. 02

    Slack can slide into mediocrity

    One blunt dissent argued that this advice becomes an excuse to coast. The objection is worth keeping because some teams do use “reserve capacity” language to normalize low urgency and weak execution. Slack only pays off if it is converted into better decisions, resilience, and selective high-impact work. If it turns into aimless underperformance, the critics are right.

    Judge reserve capacity by output quality and responsiveness, not by how calm the calendar looks. If your team claims it needs slack, you should still see stronger systems, better prioritization, and fewer self-inflicted emergencies.

      Attribution:
    • gdevic #1
  3. 03

    Incidents do not usually fix themselves

    A direct factual pushback targeted the post’s claim that most incidents resolve on their own. In many production environments that is simply false, and believing it can justify underreacting when customers are actively affected. The stronger version of the article’s argument is about not thrashing on every alert, not about assuming outages are harmless or transient.

    Be careful turning a heuristic about calm incident response into a rule of thumb about incident severity. Reserve capacity should improve response quality, not make teams slower to act when production is actually broken.

      Attribution:
    • jeffrallen #1

In plain english

glue work ↩
Important coordination and support work that helps a team function, such as documentation, onboarding, planning, or unblocking others, but is often less visible than feature delivery.
on-call ↩
A work arrangement where engineers must be available to respond to incidents or outages outside normal hours.
presubmit ↩
An automated check that runs before a code or configuration change is accepted, to catch errors early.

Reference links

Books on slack and sustainable work

  • Slack by Tom DeMarco
    Cited as a book-length treatment of keeping reserve capacity in teams and organizations.

Articles and reference concepts

  • Hofstadter's law
    Referenced to reinforce that software estimates tend to run long even when you account for that bias.

Podcast and industry anecdotes