Contra "Glue work considered harmful"
47 points by nrposner
47 points by nrposner
I think what original article says is, «if the company is broken and you are not in position to fix it, you should not seek to be the one paying for the brokenness». What this article convincingly explains is «the company being broken is bad, actually», and how to do better.
However, it is in fact better if companies that insist on staying broken do not get sacrifices from employees. Large tech companies are not worth any effort they are not paying for in liquid assets. Working at a C-quality organisation is already settling for mediocrity, doing A-quality work there just lets the company deal more damage.
The original article is about maintaining access to getting anything done at all, and also to getting anything rewarded, at a broken company one cannot fix. I don't think that the (good at what it actually is!) response about how not to be so broken is a true «Contra», and I don't think that extrapolating from way-less-broken companies to more-broken ones is a safe activity.
I think this is a defensible reading of the original post if you bring your own cynical frame to it. I think many readers, especially more junior ones, might not.
I would say that the key part about correct framing is reading the blog's «About» and noticing the explicit «large-company dynamics» call out among the three sentences there.
A junior developer paying attention to that as the applicability condition will correctly become more cynical about large companies. A reader not paying attention to «About» but paying careful attention to the presented logic might notice that this doesn't fit their workplace (good!) or maybe it does fit…
It is true that the original article tries to frame things under assumption that the large company is good but misguided. I think this is mostly works to bring correctly cynical conclusions to insufficiently cynical readers (who pay attention to the general frame of large-company dynamics though!); to a more experienced reader it might help to internalise — and tie to supporting logic — your point about growth for growth crowding out any more constructive goal. It might be a bit of a mental comfort mechanism, too, maybe partially due to sincere interest in things that get done by large companies only.
The conclusion from either of the articles taken without validation of the rest of the logic against observations risks being inapplicable to the local reality.
100% this. I ran myself ragged in a huge, dysfunctional, company and also watched several of the best engineers burn themselves out.
Your best course is resume-driven-development so that you always have the option to leave.
Well, maybe resume-driven development as typically understood is the version best optimised for leaving for other large companies; for moderate size there are a few different types with different enough getting-hired tactics not to identify them with the same kind of RDD, and unlike the huge case, there is some choice of which risk/dysfunction profile is less personally painful…
Goedecke is quite accurately describing some of the incentives presented to employees at big tech. My problem with the post is that he tells you to internalize them instead of keeping in mind that a better world is possible.
That’s his thing.
Yeah, if you work at Oxide like OP or a similar small-medium company that has attracted a higher concentration of talent, then the bigco advice doesn’t really apply. The most I might riff on the post as applied to bigco is that unbelievable inefficiencies enacted over a long period of time can create space for dramatic improvements you can take credit for.
I really appreciate this retort. I always found the original annoying for being too simplistic.
Your job is to execute the mission of your company’s leadership.
One problem with the original framing is that it assumes the company's leadership considers their strategy all encompassing. I don't know know of a single corporate E suite that would make that claim.
I don’t know, I suspect if you asked leadership about their main concerns regarding their reporting workforce, “alignment” (the word used before it became an AI thing although with basically the same meaning) would probably be top-of-mind.
I had been fighting against glue work quite a bit before LLMs for a fairly specific use case (audio / video / data processing plugins for media arts software).
I find it really wild that anyone could think that glue work is not something to be entirely automated (in my case, through C++ metaprogramming rather than IA: https://cnrs.hal.science/hal-04090584 / https://github.com/celtera/avendish) ; the impact of this is just that we could do so much more interesting work for everyone involved, done in a shorter amount of time, rather than writing absurdly error-prone repetitive switch statements to glue things together.
And yes, making this library was glue work, but a one time investment that is now paying dividends every day because I won't ever have to do it again in that context. Now we're just at the meta-level of that with LLMs.
You seem to be using the term glue work differently from the article. The definition used there is mostly social: Helping onboard new peers, helping make sure that the team has a coherent technical vision, and that the people working on different parts of the system are aware of it, etc.
I don't think that's easy to automate with C++ templates.
You're talking about glue code maybe, which is completely different.
No, not really. I went back and read the original post and it includes writing more unit tests as an explicit example of glue work. I don't think they're completely different — I've found that a lot of it is a combination of technical and social bits (writing more documentation being an example of something that's right in the middle). https://www.noidea.dog/glue
edit: ah I see (on desktop, wasn't clear on mobile) that it wasn't a response to me. Sorry!
Ah, different kind of glue work! The original piece is three links deep by now, so this was a misunderstanding waiting to happen.
Her is the abstract of Tanya Reilly's Glue Work talk:
Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team won't be as successful. But now someone's suggesting that you might be happier in a less technical role. If this describes you, congratulations: you're the glue. If it's not, have you thought about who is filling this role on your team?
No? I'm using it in the original sense, and very much including documentation, onboarding and mentorship in my meaning. The flake pattern catalog is onboarding material for team members just as much as it is for agents, for example.
As my post says, the distinction between feature and glue work has largely disappeared for me. Sometimes the best way for me to be helpful is to write code, and at other times to take notes or write a design document. Much glue work can be automated, but some cannot.
edit: whoops, like the other post I see (on desktop) that it wasn't a response to me. Sorry! I'll let this comment stay up for clarity.
Argh, I honestly thought your comment had no replies yet. Sorry, I didn't mean to pile on.
Does anyone recognise this mistake? It's not the first time I've misread the UI like this. 'This comment has replies / has no replies yet' is somehow not entirely obvious to my eye.