5 ms·

I've come to the conclusion that drawing these distinctions is actually harmful in the long run. Software engineering requires operational understanding. If you

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.

dannypgh 10y ago
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.
- user5994461 10y ago
  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.
  - alrs 10y ago
    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 10y ago
      [deleted]
- toomuchtodo 10y ago
  > I think it's true that you want everyone to be good at everything You can't fix unrealistic expectations.
  - dannypgh 10y ago
    It's not that unrealistic, as long as you have a wide enough definition of "good." I don't think you want to hire someone for an SRE role who doesn't understand algorthims well enough to do detailed analysis of the codebase, including, say, rudimentary big-O analysis of the code. Good SREs read quite a lot of code and if they're debugging a performance issue and the code contains portions that are obviously exponential or factorial in time, you want them to be able to see and recognize that quickly as a potential cause of the problem being debugged. The same is true of problems caused by bugs or anything else. Likewise, good understanding of what's possible and not possible with software is necessary for area to file (or potentially close) reasonable PRs for the codebase. The person who thinks in terms of page faults and systems analysis may take a little more time to find the optimal algorithm for an abstract problem than someone who only thinks of abstract problems. But they should know enough about software and computers to recognize the limits of their knowledge, and that's the hard part.
jonaf 10y ago
While I share your sentiment, don't forget that there is a very large pool of prospective employees who may be beneficial to a company in spite of a more narrow skill set, even if they don't grow their skill set. Take college grads for example. They're relatively inexpensive and have a moderate skill set as they begin their careers. Are they useful to hire? Yes. Do they know anything about operations? No. Is it necessary for them to? Not from day 1. They have a lot to learn, and early on, they may be more effective to an organization in a more narrow role. Let's try not to stereotype all engineers who are looking for employment into "already has all skills" and "cannot hire because lacks all skills" buckets. There's a scale, and some set of skills can be very effective for some organizations, even if they aren't quite where you are. I'm probably being pedantic, but I felt it necessary to highlight the implicit assumption.
- douche 10y ago
  You do have to have the willingness and ability to give on-the-job training to cultivate those skills, which is often wanting.

dannypgh 10y ago

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.

user5994461 10y ago
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.
- alrs 10y ago
  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 10y ago
    [deleted]
toomuchtodo 10y ago
> I think it's true that you want everyone to be good at everything You can't fix unrealistic expectations.
- dannypgh 10y ago
  It's not that unrealistic, as long as you have a wide enough definition of "good." I don't think you want to hire someone for an SRE role who doesn't understand algorthims well enough to do detailed analysis of the codebase, including, say, rudimentary big-O analysis of the code. Good SREs read quite a lot of code and if they're debugging a performance issue and the code contains portions that are obviously exponential or factorial in time, you want them to be able to see and recognize that quickly as a potential cause of the problem being debugged. The same is true of problems caused by bugs or anything else. Likewise, good understanding of what's possible and not possible with software is necessary for area to file (or potentially close) reasonable PRs for the codebase. The person who thinks in terms of page faults and systems analysis may take a little more time to find the optimal algorithm for an abstract problem than someone who only thinks of abstract problems. But they should know enough about software and computers to recognize the limits of their knowledge, and that's the hard part.

jonaf 10y ago

While I share your sentiment, don't forget that there is a very large pool of prospective employees who may be beneficial to a company in spite of a more narrow skill set, even if they don't grow their skill set. Take college grads for example. They're relatively inexpensive and have a moderate skill set as they begin their careers. Are they useful to hire? Yes. Do they know anything about operations? No. Is it necessary for them to? Not from day 1. They have a lot to learn, and early on, they may be more effective to an organization in a more narrow role. Let's try not to stereotype all engineers who are looking for employment into "already has all skills" and "cannot hire because lacks all skills" buckets. There's a scale, and some set of skills can be very effective for some organizations, even if they aren't quite where you are. I'm probably being pedantic, but I felt it necessary to highlight the implicit assumption.

douche 10y ago
You do have to have the willingness and ability to give on-the-job training to cultivate those skills, which is often wanting.