"Why is it desirable for software engineers to practice ownership over their code?"
* everyone with commit privs should also
* have the ability to deploy and roll back their code, and
* debug their code live in production.
Still more or less tracks, but now I feel these are less rules,
Another way to put it might be,
That's software ownership.
(It definitely means that everyone who writes code is expected to support it in prod, in some way or another.)
It's because we have learned through long hard suffering that ownership is the only way to deliver quality service for users.
If you ship a change and lob it over the wall and it breaks, you are the person best equipped to debug and fix it. This truth sits at the heart of all the feedback loops we construct,
That's just cruel and stupid.
I don't remember exactly where I was, so let me throw out two links that should be read by anyone who claims to give a shit about the future of our profession.
stripe.com/reports/develo…
Key finding: developers spend ~40% of their time on what I think of as "technical bullshit": deeply technical labor that does not move the business forward or provide value.
devops-research.com
Key finding: only 3.5% of teams are high performing on the only metric that really matters, which is time elapsed getting code to users. And velocity increases and failures decrease in tandem. (More: )
It is a testament to human homeostasis that we accept this as somehow normal and okay. Our single most valuable asset, and we burn it up cause flames are pretty. (Then bitch on how we can't hire!)
It's mostly the accumulated friction and debt accrued by years and years and years of building systems we don't understand and cannot observe. Patching symptoms and workarounds. Sedimentary layers of bugs submerged for eons.
Shit got more complicated, we built tools and processes. Roles emerged and soon we had code experts (dev) and system experts (ops).
It was killing us, but we took pride in it.
The people who were feeling the pain had no context on what had changed or what the original intent was. They had no ability to fix it at the source either -- just duct tape.
🧚♀️ Wave one of devops: "ops must learn to write code!". Cool, done.
🧚♀️ Wave two: "devs must learn to build operable services." In progress, I'd say.
They exist to mend the feedback loops between engineers and their code, running on prod, by users.
I don't mean this to sound grim. It's not. There will always be good work for a good systems engineer, and the work is getting qualitatively less shitty and more fun.
Ops engineers are shipping code, embedding as SRE, and going to companies where they can solve operational category problems for everyone.
If not now, soon. It's coming.
But that's not what's on offer. Abuse and misery are not inevitable when running highly available systems.
Feedback loops are not a punishment. They mature you into a wise elder engineer. They give you agency, mastery, autonomy, direction.
FIN