I think I figured out why arguments like "an engineers should be on-call" or "all engineers should be deeply involved with production/ops" bother me.
It's not that I disagree, but it sometimes implies an untenable expansion of what a person's job is.
It's not that I disagree, but it sometimes implies an untenable expansion of what a person's job is.
Good version: when your branch is merged, you're expected to be available for 60 minutes afterwards if errors crop up in production. No clicking Merge at 5:30pm on Friday and hopping in a car to go camping.
You were expected to write a feature. This is part of it.
You were expected to write a feature. This is part of it.
Another good version: put devs on call because the site has reliability issues, and it's suspected that not enough people know where to look for low-hanging fruit. Getting more eyes on the problem helps.
You were expected to build and maintain a service. This is part of it.
You were expected to build and maintain a service. This is part of it.
Bad version: the person who set up Kubernetes quit, so we're going to put all devs on call to make sure they can fix the cluster when it breaks. Oh, also, you're expected to keep churning out features at the same rate.
You were expected to ... what, work 2x the hours?
You were expected to ... what, work 2x the hours?
The problem is not asking people to do more work that is important. The problem is asking them to do more work, with no tools to make it easy, no guidance on priority, and with no conversation about why it's happening.
This is not a rant about full stack devs or devops-is-a-culture-not-a-toolset. This is about highlighting that sometimes, work is work, and knowing that there are companies who have made that work trivial doesn't make your company work that way.
That said, sometimes work is not work, because you can hand somebody a tool and a problem, and it won't take them that much time to solve it. Tooling does make things better, and while the setup and learning curve costs are real, it can drive down a bunch of marginal costs to 0.
Why does @mipsytipsy want more devs to pay attention to their features through the "fourth trimester," in prod, with actual users? Because @honeycombio makes it easy to see how it's behaving out in the real world.
Why does @edith_h want product managers to care about rollouts? Because with @LaunchDarkly makes it possible for them to do it without learning all of engineering.
Why do I want you, an engineer NOT on the infrastructure / platform team, to care about reliability and load balancing and traffic shifting? Because @GoTurbine makes it easy to configure, just for your service. Start with a default. Make small changes.
Having more context in one brain produces better decisions. Coming up with the policy "if a request takes longer than 1.5s, retry it once before returning a 500" isn't the hard part. It used to be setting up the tooling that was hard. Today, it's just easier.
If you're a manager, ask your team to take on more context and make bigger decisions, but support them with tools, education, and reasonable expectations.
Everybody, ask yourself what you could take on, if you had the right support.
Everybody, ask yourself what you could take on, if you had the right support.
