,
11 tweets,
3 min read
Read on Twitter
when you just deploy and walk away without checking -- is it doing what you thought it would, does anything else look weird? -- you're depriving yourself of so much tasty dopamine. you're leaving an open loop, a dangling question, an invitation to anxiety.
so ❣️check❣️
so ❣️check❣️
btw i realize i have been mostly addressing the devs in the room on this topic, not my own peeps in ops, i assume y'all already know this. i'll say it anyway:
developers becoming literate in operational skills does not threaten our livelihood one squat tiddlywink.
developers becoming literate in operational skills does not threaten our livelihood one squat tiddlywink.
the ocean of infrastructure wisdom it takes to operate systems in the distributed age is more vast than ever before. people who love to specialize in reliability engineering and operational expert systems topics are always going to be in demand.
(but..)
(but..)
the shape of where and how ops engineers are needed is shifting, no doubt. six or seven years ago, startups like Parse expected to hire a team of ops/SRE's fairly early on, and we didn't expect to contribute to the product much at all, only infra & dbs.
ops engineering is increasingly a specialty, and basic ops is increasingly accessible.
no more "every startup gets an ops team for the SWEs to lean on". instead, ops folk will be solving category problems at larger co's, or working as hybrid product/ops engineers at startups.
no more "every startup gets an ops team for the SWEs to lean on". instead, ops folk will be solving category problems at larger co's, or working as hybrid product/ops engineers at startups.
i was just checking my twitter replies (for the first time in five days, lol) and a couple people parried my assertation about senior SWEs needing ops skills with "does this mean senior ops engineers need some frontend exp?"
no; they should should have some *product* experience.
no; they should should have some *product* experience.
and i don't just mean "be a decent programmer". i mean gathering requirements from stakeholders, planning and setting deadlines that aren't just guesses, working with larger code bases and improving and refactoring as they go, working with design, giving product feedback, etc
being a purely reactive operations engineer, or only writing glue and automation code, is going to become less common or valued over time.
(hey, this hurts me too, kids. i've never harbored any desire to sit down and stare at the same piece of code for weeks on end.. blech)
(hey, this hurts me too, kids. i've never harbored any desire to sit down and stare at the same piece of code for weeks on end.. blech)
that said, it's the first thing i'm gonna try and do next time i'm free to switch into new-engineer mode for a few months. i bet i can find something to care about long enough to level up at product eng a bit.
we gotta keep up and push ourselves, just like we push them. 🥰
we gotta keep up and push ourselves, just like we push them. 🥰
this industry moves so fast. pushing the envelope means you learn to enjoy being uncomfortable as a way of life. and if that exhausts you, there is *no shame* in shifting into another gear. plenty of java programmers still getting paid, y'know?
*ducks and runs*
*ducks and runs*
