HN

Comments (116)

• Menu

  Arainach
  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.
• Menu

  wiseowise
  > 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.
• Menu

  hintymad
  > 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.
• Menu

  macNchz
  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.
• Menu

  hilariously
  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.
• Menu

  garrickvanburen
  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."
• originalvichy
  As a person who has worked in many customer-facing jobs, the worst trap I faced numerous times is befriending a paying client. It becomes insanely difficult to say no to a client when hired as an expert for their assistance, when they are a genuinely pleasant person.It’s made worse when they are not a decision-maker, but someone who gets forced to push me to do something. As a trusted expert, it’s easy to say no to bad ideas when the client is the one doing them, but when the orders come from their boss who you never interact with, you’re placed in a position where you either appear as a useless cost, or a yes-man who’ll leave behind a monstrosity.I sometimes envy some of you guys who worked primarily internal gigs where you could at least try to reason with someone up the chain.
• Menu

  o_nate
  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.
• black3r
  I probably spend even more than 20% of my time away from the computer these days. AI is great for this. I task Claude with something and while it's working I have the time to think about next steps, I can take a walk outside, have a coffee, talk with coworkers about my ideas, ... I'm paid to think, not to sit behind a computer.There are people who say it's better to have multiple claude code instances crunching different stuff at the same time, and using the waiting time to prompt up another one. This might result in opening up more PRs faster but in the end it's not more productive. Context switching takes time, it divides your attention so your work is more sloppy and less thought through, and driving your brain too much makes you tired which again results in more mistakes. Having to compensate for this negates the productivity gains by finishing more grunt work faster.
• zem
  the bit about glue work is interesting, because in my time working for megacorps this has been an explicit part of the annual performance review (google called it "citizenship" which I think captured the essence of it - basically "what work did you do to make things better for the rest of the company").on one hand it does seem a bit messed up - this was not in my "job description", so it was technically unpaid work that was nevertheless a formal part of my expectations. but on the other hand I really liked working in an environment where everyone spent some of their time and effort to improve things for everyone.also making it an explicit requirement for everyone to do at least attempted to circumvent the more toxic culture of "I am a rockstar engineer and I'm busy doing important things, someone else can do the glue work". not to mention that "someone else" usually ended up being a woman, and that she was almost certainly getting paid less than said rockstar engineer.the OP's implication is that the company should have formally hired someone to do all the glue work, but it is usually made up of enough diverse pieces that it would be practically impossible to hire a single person to do it - e.g. what sort of job title would cover "write documentation, interview software engineers, and organise a team off-site"? but those were all tasks that needed to be done and the citizenship requirement let the burden be distributed more fairly.I think a better way to put it is not "don't do glue work" but "don't be the only chump doing unrewarded glue work", i.e. to push for a company culture where everyone is expected to do some of it and where it is formally recognised as work.
• Menu

  codewarrior2000
  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.
• Menu

  dilyevsky
  Tom DeMarco had a whole book about this approach: https://www.penguinrandomhouse.com/books/39276/slack-by-tom-...
• ge96
  Haha that's me right now, I'm enjoying it, I used to be gung ho wanting to be somebody but now it's fun coastingI've been focused on going out/socializing more which is unfortunately distracting me in life, all I can think about is going out getting laid
• rznicolet
  This reminds me very much of Buffer Time from Star Trek: Lower Decks, but applies pretty well to a lot of life. No slack = no margin for error or the unexpected...
• rokhayakebe
  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.
• Menu

  NoSalt
  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.
• sghiassy
  Come join Meta. Everything here runs at 120% haha
• Menu

  12_throw_away
  Sigh. This article is obviously completely correct, but I don't think the people who actually need to read it will care.Running anything at constant 100% utilization means you are going to be working in crisis mode all of the time. Even in factory labor, the Toyota Way is several decades old now, and it involves making sure everyone has at least a little breathing room to step back and think about what they're doing. And obviously this is even more important for "knowledge workers" or anyone whose output requires any amount of creativity.High functioning organizations have a good (not too much, but not too little) amount of slack in their work pipelines. Pretty sure there is not a single person with an MBA (or, lol, any consultants) that knows this anymore.
• Menu

  gdevic
  Great recipe for mediocrity. Do not follow OPs advice. (Source: 23+ years at NVIDIA).
• 3uler
  This makes me never want to work on large engineering teams ever again.
• Apocryphon
  It's kind of refreshing to see a "pontificating about what it means to be a SWE" blog post that doesn't have anything to do with the industry impact of LLMs. Like it's 2013 again.
• skybrian
  This sounds a lot like being on call. If you like that kind of work, why not be an SRE instead? Maybe there also need to be people “on call” for responding to other kinds of events, though?It also sounds a lot like getting pulled into meetings. People complain about it, but sometimes that’s the job.
• Menu

  singpolyma3
  This is mostly all true. At my last corporate job I definitely did this and it was very good for my career.It also made me hate my life.
• thewileyone
  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.
• casey2
  Software allows clever people in a lucky position to benefit from the massive amount of work people have done before them. You should remain discipline so that when you do get your opportunity you don't add on to the garbage pile.
• jeffrallen
  I wanted to love this, but:> Most incidents resolve on their own.This is most definitely not true.
• Menu

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

  jazz9k
  This is written as if you have actual control over the volume of work given to you and/or deadlines.
• erelong
  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 speakingOtherwise I don't see why you couldn't do lower value tasks with flexibility to abandon them if something higher value comes up
• SpecStudioHN
  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.
• ath3nd
  [dead]
• throwaway67678
  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)