Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
- Tom DeMarco had a whole book about this approach: https://www.penguinrandomhouse.com/books/39276/slack-by-tom-...by dilyevsky
- fantastic book.
- 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.
by zem - That does sound nice. I think the author would say that if it's part of your annual performance review, then you are being paid to do it. That's the real test, not the job description, which can't be expected to describe every single thing you end up doing once employed.
- 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.by Apocryphon
- Right. Maybe HN should add tags `Classic HN` to posts like this. Or we could flag it as `Classic HN` lol ...by palerdot
- 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'd argue 80% is high. This also varies between Devs. The way I learn, think about things, struggle to get started etc, means my 80% is no way near say, another colleagues' level who's simply stronger technically. Factor in any degree of NT tendency, and one person's 80 is anothers' 120.by martin-uk-
- 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."
- I know this is a code about me behaving as if I went to a world-class university for undergrad. I could have gotten into almost any world class university, so that's what I do.by mwhite
- 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
- Except ... the collapse never happens. Once your engineers burn out or age out you just hire fresh meat and the cycle repeats. The issue I have with these types of articles (and books like Peopleware / Slack) is they never provide any actual metrics that may convince the beancounters to try a different approach.by stuxnet79
- Efficiency is the enemy of resiliency.by xnx
- 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 - or if youre like me you end an RPG with like 29 ethers that using early would have made life a lot less grindyby boogieknite
- One thing I've noticed myself, if you are not sufficiently challenged for a while it can be extremely difficult to surmount the next challenge. Peak "abilities" for me in whatever categories has always been when I had enough work in front of me to just chug away like a machine, and enough trust where I didn't need to stop and constantly explain myself but could just work uninterrupted towards the goal. Skills would grow like wildfire and tasks would be completed sooner than expected.
Unfortunately very few jobs are structured to take advantage of that. So many blockers and distractions from you getting into actual deep work.
by asdff - 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
- > take your estimate of how long it will take to do something and double it before communicating to your manager/users.
Yeah, but did you take Hofstadter's Law into account?
It always takes longer than you expect, even when you take into account Hofstadter's law.
by Sohcahtoa82 - Kent Beck (maybe in Good News Factory but also in talks) that his team would never commit to more than half what they think they can get done. This is a good way to sustainability. And that's the optimization and precedent to set; that we are here for the long term, delivering steadily at a sustainable pace. It's a long game, and over promising only runs down trust, which is your biggest means too getting the space we need as Devs. Under promise, build trust that we can do what we say, earn the space we need to not burn out. Honestly the more senior I get (Lead), boundary setting and preserving my attention; not burning out, _is_ the job. Because there are myriad ways to do this to yourself.by martin-uk-
- > 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 - Can't solve a problem that doesn't exist yetby bauldursdev
- I read the section you quoted as being about saving the day in an incident that's already in progress.
- Many carears are made and bonuses paidout with heroesim trick.by johnnycool
- It’s about what people notice. In town governments I’ve heard of cutting popular programs that will provoke an outcry only to get credit for reinstating them, while possibly smuggling through other actions that are necessary but unpopular.by mjklin
- Also, disaster is a good signal to the higher ups that there are problems in your org. If you keep putting out every fire with heroics, your boss will know (maybe), but his boss's boss's boss will see that your org is doing great and everything is all code green.
If you let a few things burn down, your boss's boss's boss will notice the fire, and things may improve. It's perhaps the easiest way you have of communicating with them.
- The examples of high impact all seem like things unlikely to receive recognition.
If you save a sales deal, they'll cheer the sales staff. And pay them a commission, which you will receive no part of.
by nitwit005 - I learned this early in a conservative org. Preventing things is risky. Just keep the solution ready for when things go wrong because then you'll get approval.by tormeh
- > 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 - hmmm...
At good companies, they have a culture, and people help each other out.
Like lunch-table talk that helps people understand things.
But yeah, maybe not doing hours of work for someone.
by m463