lknfrnpt

"It's a marketing term"

...

"Practice root thinking [1]"

[1] "Term _I_ coined"

I'd love to dig into this a little bit. Any ideas? The hypothetical examples that stand out to me are security engineering type roles in which the teams in question might not actually own the operations of infrastructure they build/maintain. I know a tiny set of people who work on operating systems at various levels for consumer devices (i.e., Android these days). How prevalent are those jobs? How do they stack up in terms of comp and hiring demand?

If you work on backend at a small to medium sized organizations, it is pretty common to be expected to own what you ship beyond landing pull requests: deploying, operating, migrating, oncall, etc.

(Yes)

I take pride in caring about what matters most for customers (such as end customer impact during production incidents, but also in general prioritization). This is why it's stressful to be on call at times, because I don't let myself truly relax and do normal life things outside of work (because taking a laptop everywhere isn't compatible with some activities).

It's possible to believe in a company mission, and even to drink the company Koolaid to the extent one might romanticize on YN (I did in my early days, while also resentful of the demands of oncall), but it is not necessary to give all the hours of your day to any company. Also, I do enjoy engineering, so your hypothesis is also off base in that regard (in fact I don't really care much for the idea of professionalism). I know plenty of accomplished and happy people for whom work is just one part of their lives and not their defining attribute.

In my experience infosec is more preventative; writing secure code reused by a larger org, reviewing designs from non security teams, maintaining automated monitoring and yes when it happens responding to incidents. Rarely just fixing code issues!

Doesn't sound so bad as I write it and remember it... :)

"If having people on-call 24/7 seems normal to management, they need to step up and address the bugs, failures, downtime, and the lack of redundancy, monitoring, and automation."

"I would strive to get the support burden down to a very occasional alert on my phone that I can respond to from my phone."

It's possible we're working on different kinds (or scales) of software or differently sized organizations – there are no human customers actually "calling," nor can you typically resolve true production incidents (let alone root cause them or estimate impact) from a phone.

At the companies I've worked, there are no architect roles; architecture is the responsibility of ICs pretty early on (in addition to implementation and ownership of operation). I've seen this at both small startups and large FANG-like companies. Any companies in mind with this sort of role? Thanks!