개발 이야기를 좋아합니다.
- Tweets7K
- Following2.4K
- Followers11.8K
- Likes34.5K
ALT “Glue work” is an concept Tanya Reilly came up with in 2019. The idea is that there’s a large amount of unglamorous work that every team needs in order to be efficient: updating the docs and roadmap, addressing technical debt, onboarding engineers, making sure people talk to their counterparts on other teams, noticing strands that are getting dropped, and so on. Practical, naive engineers gravitate to this work because it’s obviously useful, but at promo or bonus time they’re ignored in favor of the engineers who did more visible work (like delivering new features). I think this concept is excellent. It’s why I keep saying that shipping projects is so hard — if you’re the kind of engineer who’s used to just putting their head down and writing code, you won’t have the tools to do the glue work that is actually needed to deliver anything successfully. Pure hackers don’t ship. You need to be able to actually deal with the friction in a large organization in order to deliver value.
ALT So why doesn’t glue work get you promoted, if it’s so crucial to shipping projects? Are companies stupid? Are they deliberately leaving value on the table? No, I don’t think so. Companies don’t reward glue work because they don’t want you prioritizing it. And they don’t want you prioritizing it because they want you shipping features. Glue work is hard. If you’re capable of doing glue work well, they want you to use that ability to deliver projects instead of improving general efficiency.
ALT The engineer who says no all the time is a real archetype among senior and staff engineers. Their role is to slow things down, to block the development of features that add complexity, and to ensure that as little code gets written as possible (since code is a liability). We can think of this as the just-say-no engineer, as opposed to the just-say-yes engineer. The just-say-yes engineer is obsessed with moving fast, approves code changes by default, values MTTR over MTBF, and tends to ship a lot of code. The just-say-no engineer is obsessed with quality, is happy to move slowly, and blocks code changes by default. Most engineers are somewhere in the middle of the spectrum. By “just-say-no engineer”, I’m talking about the group of engineers who most strongly identify with that archetype.
ALT The just-say-no engineer is having a hard time in the era of AI. It used to be that they only had to say no to more junior engineers’ handwritten PRs, but now they have to say no to a barrage of AI-generated code, some of it generated by managers and VPs who are politically difficult to say no to. For the first time in their careers, they’re under a lot of pressure to lower their standards and start saying yes. However, this isn’t because of AI. It’s because of the end of ZIRP. ZIRP and the just-say-no engineer
