I say ‘feasibly’ because often the upper end of career ladders for Independent Contributors (ICs) could be paraphrased as “we’ll know it when we see it”, which can leave those who haven’t sufficiently proven “it” in a frustrating limbo. ​ I’ve worked very hard to become an engineer and I want to stay here. ​ Developing prototypes to further explore and support ideas that come from that research.

Fear of deploys is the ultimate technical debt. ​ Deploys are the heartbeat of your company. ​ as pedestrian as the day of the week. ​ Deploy on every commit. Smaller, coherent changesets transform into debuggable, understandable deploys. ​ If you do not block merges on Fridays, and only block deploys, you are queueing up a bunch of changes to all get shipped days later, long after the engineers wrote the code and have forgotten half of the context. Any problems you encounter will be MUCH harder to debug on Monday in a muddled blob of changes than they would have been just shipping crisply, one at a time on Friday. Is it worth sacrificing your entire Monday? Monday-Tuesday? Monday-Tuesday-Wednesday? ​ have all happened after holiday code freezes. Every. Single. One. ​ The “safety” of nodeploy Friday is realized immediately, while the costs are felt later later. ​ Finally, I heard from a alarming number of people who admitted that Friday deploy bans were useless or counterproductive, but they supported them anyway as a purely symbolic gesture to show that they supported work/life balance. This makes me really sad. I’m … glad they want to support work/life balance, but surely we can come up with some other gestures that don’t work directly counter to their goals of life/work balance. That's it. Because if you make it a virtue signal, it will NEVER GET FIXED. Blocking Friday deploy is not a mark of moral virtue; it is a physical bash script patching over technical rot. And technical rot is bad because it HURTS PEOPLE. It is in your interest to fix it.

a lot of my maturation as a developer has come from realizing that intuition is a disease and a crutch rather than a thing that should be relied on in lieu of formal verifications: the goal should be to delay intuition until it is reified in a thing that exists beyond your mind.

Sharing suffering is actually one way to minimize suffering, and minimizing suffering is at the core of my beliefs on compassionate teams. ​ If you're a senior engineer wondering what's next, try turning your attention to your team. I would bet that you'll learning something worthwhile.