Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

plus.google.com

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#11

Post by dannypgh »

dkarapetyan wrote: post #6

I've come to the conclusion that drawing these distinctions is actually harmful in the long run. Software engineering requires operational understanding. If you hire programmers that do not know how to spin up a VM and codify their deployment processes then hiring SREs is not really going to fix anything.

I think it's true that you want everyone to be good at everything- you want engineers writing tests for their own code, you can't just hire software engineers in test and make it their problem.

The distinction is practically useful because not everyone is an expert on everything, and if you focus your hiring around very narrow markers- e.g. ability to work with algorithms to solve a coding interview- you may not build an organization that has balanced expertise.

Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots. The software engineer who spent lots of time thinking about operating systems, Linux internals, and how to build reliable systems out of unreliable parts bring value to the organization in the same way that engineers who focused on mastering algorithms bring value. Everyone needs to be strong in everything, but in practice we have different strengths, and getting people with different strengths together seems to be a good idea.

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#12

Post by techman9 »

mark212 wrote: post #4
mark212 wrote: post #2

not once does the writer explain what she means by "SRE" -- yet uses it repeatedly. Spend a few words early on to define your term and then go ahead and abbreviate away. That's just writing 101.

had to go all the way to her Google+ bio to find out that she's a Senior Site Reliability Engineer, so I'm guessing that SRE in this essay means that.

It's also in the title of the link on HN?

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#13

Post by taesis »

mark212 wrote: post #2

not once does the writer explain what she means by "SRE" -- yet uses it repeatedly. Spend a few words early on to define your term and then go ahead and abbreviate away. That's just writing 101.

AcronymFinder.com works pretty well when you encounter an acronym you don't understand. In this case, you'd have to hit the 'Information Technology' section, as will frequently be the case on Hacker News.

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#14

Post by closed »

lukasb wrote: post #5
mark212 wrote: post #2

not once does the writer explain what she means by "SRE" -- yet uses it repeatedly. Spend a few words early on to define your term and then go ahead and abbreviate away. That's just writing 101.

if you don't know what an SRE is, you're not the intended audience. probably half of the articles posted to HN are unintelligible to non-practitioners of that particular subfield, don't see why this should be different.

I don't know. As a person who is part of a number of intended audiences, I still get frustrated when people (directing things at me) don't define acronyms when they're first used, since

1. it's a hinderence for people who are studying to become the intended audience.

2. sometimes I'm reading two literatures that use the same acronym, so it's momentarily stupifying.

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#15

Post by user5994461 »

dannypgh wrote: post #11
dkarapetyan wrote: post #6

I've come to the conclusion that drawing these distinctions is actually harmful in the long run. Software engineering requires operational understanding. If you hire programmers that do not know how to spin up a VM and codify their deployment processes then hiring SREs is not really going to fix anything.

I think it's true that you want everyone to be good at everything- you want engineers writing tests for their own code, you can't just hire software engineers in test and make it their problem. The distinction is practically useful because not everyone is an expert on everything, and if you focus your hiring around very narrow markers- e.g. ability to work with algorithms to solve a coding interview- you may not buil…

Algorithm = skill that everyone has, cheap and easy to get.

OS + linux internals + reliable systems = 3 non trivial skills, harder to find and more expensive. The combination is definitely rare.

> Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots.

If you break out the skills and hire for them independently. You'll end up with a lot of people with the common skills and barely anyone with the rarer skills and the ability to train them to others.

I agree with getting people with different strengths together. It's a NP-complete hiring problem though.

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#16

Post by alrs »

user5994461 wrote: post #15
dannypgh wrote: post #11

Earlier quoted context omitted.

I think it's true that you want everyone to be good at everything- you want engineers writing tests for their own code, you can't just hire software engineers in test and make it their problem. The distinction is practically useful because not everyone is an expert on everything, and if you focus your hiring around very narrow markers- e.g. ability to work with algorithms to solve a coding interview- you may not buil…

Algorithm = skill that everyone has, cheap and easy to get. OS + linux internals + reliable systems = 3 non trivial skills, harder to find and more expensive. The combination is definitely rare. > Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots. If you break out the skills and hire for them independently. You'll end up with a lot of people with the common skills and bar…

In my early sysadmin years I knew absolutely nothing about algorithms while untangling infrastructure messes spawned by the educated. Most of the good ops people were scratch-and-dent smart people who came to the field without the benefit of any kind of CS education.

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#17

Post by icebraining »

contingencies wrote: post #10

Cute title. For those who missed the reference - https://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs A business version would be good, something above the pure profit-motive... actualization as a moral, sustainable, environmental, socially engaged organization that gives more than it takes from society. (Note: This is critically different to the SV-dominant self-image band-aid approach of large scale post-profi…

That was the purpose behind the creation of B-Corps, which allows the company to have some public beneficial goals as part of their legal obligations, besides increasing shareholder value.

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#18

Post by Thaxll »

mark212 wrote: post #2

not once does the writer explain what she means by "SRE" -- yet uses it repeatedly. Spend a few words early on to define your term and then go ahead and abbreviate away. That's just writing 101.

devops / sysadmin / ops / system engineer pick a name.

Re: Maslow's Hierarchy of Site Reliability Engineering Needs (2015)

#19

Post by [deleted] »

alrs wrote: post #16
user5994461 wrote: post #15

Earlier quoted context omitted.

Algorithm = skill that everyone has, cheap and easy to get. OS + linux internals + reliable systems = 3 non trivial skills, harder to find and more expensive. The combination is definitely rare. > Breaking out the roles and trying to hire for all of them helps ensure you don't get blindspots. If you break out the skills and hire for them independently. You'll end up with a lot of people with the common skills and bar…

In my early sysadmin years I knew absolutely nothing about algorithms while untangling infrastructure messes spawned by the educated. Most of the good ops people were scratch-and-dent smart people who came to the field without the benefit of any kind of CS education.

[deleted]
Post reply on HN