Working at google was an interesting experience on this. Everyone there cared greatly about the topic, executives were willing to staff huge teams who worked solely on minimizing technical aspects of friction (both company-wide and for specific areas), and individuals and teams were given a massive amount of leeway to work as they thought was best.
And yet, the dev experience was absolutely unbearable. Submitting one small (already approved!) change could literally take days of intermittent work to do, and the lack of structure meant that reviews were organized completely ad-hoc. Coordinating with teammates was just “if you need to coordinate, go talk to them” plus a weekly status meeting because agile/scrum/detailed ticketing was an “unnecessary distraction”.
All of this is on top of the insane number of internal tools to learn and re-learn as they got deprecated, merged, and updated (which is a good thing, but still a time sink).
This essay is very good, and clarified my thinking on the topic to a few possibilities, where multiple are probably somewhat true at once:
1. Google-scale work is just inherently really, really hard.
2. Sometimes removing all the organizational processes in the name of developer freedom makes things worse.
3. The promotion structure might lead to overly-complicated or dubiously-useful technical processes.
4. I might just be bad, either at programming or whatever it takes to be effective at a big company.
I'm not sure I agree — if you're working on a feature and slow builds mean it takes forever to finish it, taking the time to address the tooling before continuing feature work is a valid way to build what you need.
I've worked a couple times on platforms obscure and closed enough that there basically weren't any tools. Not much specific to them, anyway, beyond the very bare bones, just whatever you could cobble together with standard CLI programs and whatever limited interface the things gave you.
These felt at least as productive as ecosystems with piles and piles of tools. And, if anything, less frustrating.
And yet, the dev experience was absolutely unbearable. Submitting one small (already approved!) change could literally take days of intermittent work to do, and the lack of structure meant that reviews were organized completely ad-hoc. Coordinating with teammates was just “if you need to coordinate, go talk to them” plus a weekly status meeting because agile/scrum/detailed ticketing was an “unnecessary distraction”.
All of this is on top of the insane number of internal tools to learn and re-learn as they got deprecated, merged, and updated (which is a good thing, but still a time sink).
This essay is very good, and clarified my thinking on the topic to a few possibilities, where multiple are probably somewhat true at once:
1. Google-scale work is just inherently really, really hard.
2. Sometimes removing all the organizational processes in the name of developer freedom makes things worse.
3. The promotion structure might lead to overly-complicated or dubiously-useful technical processes.
4. I might just be bad, either at programming or whatever it takes to be effective at a big company.