lknfrnpt

6 ms·

1.
by lknfrnpt 4y ago
"It's a marketing term" ... "Practice root thinking [1]" [1] "Term _I_ coined"
2.
by lknfrnpt 4y ago
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&#x2
3.
by lknfrnpt 4y ago
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)
4.
by lknfrnpt 4y ago
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 mys
5.
by lknfrnpt 4y ago
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
6.
by lknfrnpt 4y ago
"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
7.
by lknfrnpt 4y ago
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
8.
Ask HN: Options for back end engineer sick of oncall
13 points by lknfrnpt 4y ago|31 comments