6 ms·

Is SRE the most inflated ego job title in tech?

by faangiq 4y ago

oxff 4y ago
Software "Engineer" is (stolen valor from real world Engineers)
exdsq 4y ago
ML Engineer? Wait! No. My vote goes to AI Ethicist.
borplk 4y ago
No it's quite an accurate title and I don't think it's inflated. It's not really considered something prestigious.
- trhway 4y ago
  It is presented as prestigious in order to hire at least somebody into it. While, depending on place, work may be interesting the management usually is more rotten than say in dev.
- thematrixturtle 4y ago
  It's considered prestigious by other engineers. Outside engineering, not so much. At one point in my career I moved from a technical presales role to SRE. The engineers congratulated me on the promotion, while the sales people all thought it was a demotion. (And in terms of career progression it probably was.)
  - tristor 4y ago
    > It's considered prestigious by other engineers. I'd love to see some evidence of that. I have never been in an organization where Ops folks and SREs are treated as if those roles are prestigious by other people in the engineering org. Generally they're treated like digital janitors, and assumed to be bad at software development. I've literally had an SWE /at work/ say to my face that "You're in Ops because you weren't smart enough to pass a code interview" because they were upset I had pointed out a flaw in their design and were essentially making an appeal to the nebulous authority of their title. SRE is definitely more prestigious than being in technical presales to other engineers, but that's because to other engineers any role in the sales org is not real engineering (even if it is), and to sales people anything in the engineering org is a demotion because it means you are joining "the basement people". Sales people aspire to becoming a CEO, not to building something that makes a mark on the world. Engineers want to build the thing, they don't care /how/ they have to go about doing it (whether that's being a founder/ceo or working in the basement).
dijit 4y ago
That's not the fault of people doing the work, that's what the industry is doing to us. I get increasingly irritated with the myth that 'DevOps' are any different than the sysadmins of 10 years ago. "But DevOps can code", yes, so could sysadmins, in fact, terraform, ansible, vagrant, saltstack, chef, puppet etc;etc;etc are all made by people who held the title of sysadmin when they were written. In fact even the term "DevOps" was originally from a conference, where the idea was that "we can do systems administration in an agile way" -- NOTHING to do with coding, everything to do with getting developers and sysadmins working closely together in an iterative fashion. I would personally be very happy being called a sysadmin, but doing so is career suicide, because we as an industry have decided that sysadmins are somehow braindead, and that you really need "SREs" or "DevOps" -- despite the fact that these are the same people. What gets my goat even more is that people hate on sysadmins because of corporate culture, echos of centralised IT organisations that said no to everything. But we're doing exactly the same thing with these new titles now. It's a joke. (This text, from yesterday: https://news.ycombinator.com/item?id=31194067 https://news.ycombinator.com/item?id=31194067 ) ——- I would be very happy to be called a sysadmin again, we can take some principles from the SRE book and that’s fine. This is increasingly annoying because oh can’t be called a “engineer” in Canada, it’s a protected title. I even wrote a ranty blog post about this a couple years ago, I will post it here later. http://blog.dijit.sh/devops-confusion-and-frustration http://blog.dijit.sh/devops-confusion-and-frustration
- iaresee 4y ago
  You can be called engineer in Canada. You can’t offer engineering services to the public without being licensed. Non-PEO licensed software engineers exist in large quantities in Canada without any issues. They provide services to a company, not the public.
- prepend 4y ago
  I think the difference is that there were (and still are) many sysadmins who don’t code. So the shift was that there was an expectation that all ops people could code. I don’t think it’s solely a Unix/windows thing, but I still work with windows admins who manually set up machines. Like they set up a vm in azure and then spend hours or days pushing buttons until it’s “ready.” For one vm. A person like this should not be in ops. They should be trained and improved to automate this by code. So the world is full of “there’s always been devops” because 30 years ago sysadmins were scripting out their stuff in shell scripts and whatnot. And also “we’re moving to devops” where people still manually do system tasks.
tristor 4y ago
The title might be inflated, and maybe the egos too (but that's true across engineering disciplines), but I can tell you the pay certainly isn't inflated. While I was in Operations, I on average was paid 1/2 of what an equivalent level SWE would get paid in most companies, this was typical across the industry, and I'm guessing still is. Because SRE came out of Ops, which came out of SysAdmin, there's a cultural expectation both by other engineers and by management that you are essentially a digital janitor, and if you can code it's only minimally so that you can write glue scripts, rather than being equally capable as an SWE. The reality is that most of my peers were /better/ developers than equal-level SWEs, because they had a stronger understanding of lower level systems and their interactions than SWEs who spent all their time working in abstractions. As another commenter notes, I would have been perfectly happy keeping the "SysAdmin" title my entire career, and while I held the title for awhile, it always grated on me when people were hired as DevOps Engineers (I would often tell managers "DevOps is a philosophy, not a job title."). At least SRE accurately describes the work in some abstract sense, you are an engineer and your primary duty is the reliability of the public facing site and its dependent backend services. Frankly, the amount of derision I see here and in other tech circles from SWEs against basically every other role in tech makes me think SWEs are the ones with the ego, for that matter.
- pm90 4y ago
  > Frankly, the amount of derision I see here and in other tech circles from SWEs against basically every other role in tech makes me think SWEs are the ones with the ego, for that matter. I can believe this. It’s especially funny when building a reliable system today requires a really basic understanding of few low level system concepts (eg graceful termination, signal handling, healthchecks, DNS) and most SWEs I work with simply refuse to learn these things.
  - nickjj 4y ago
    > most SWEs I work with simply refuse to learn these things Are the SWEs over worked with unrealistic deadlines? Also how did the SRE present this information to them? I think both factors can drastically have an effect on the outcome. For example a small team who is already on the brink of being overburdened getting tossed a few links on Slack that says "please make sure you know about Kubernetes graceful shutdown timeouts and signals" with no other context is going to be met with resistance because now it feels like you're giving them another job. If they have no prior experience with that sort of thing it could take days to partially understand it. That's eating up time for their sprint, etc.. Alternatively, you could write a nice bit of documentation in private explaining the problem and why graceful shutdowns are a good thing, how it aligns with being able to deploy new versions of our apps, how they can create a better user experience for the apps they're building along with prepare anything you can to get as much information about your apps as possible (longest page responses, etc.), then spend a bit of time with your tech lead or someone who knows your applications well to iron out good values for all of your services (this assumes a worst case scenario where you don't have these metrics logged anywhere yet). Then wrap things up with a 5-10 min show / tell to share this knowledge with the devs so they have an awareness of it. In my opinion that maximizes everyone's time, the SRE doesn't even need to know much at all about the app's business domain too since it all boils down to how long an app might take to exit. Knowing a bit about the tech stack can be researched for the document you'll write too, such as mentioning how you can hook into the shutdown process of the app server to potentially execute code during a graceful shutdown, etc.. I've found that after all of that, it was embraced in a very positive way with devs now looking for ways to improve the app to better handle the app shutting down at unknown times without data loss and minimal user disruption. This is now a skill set the devs can take with them anywhere around having experience building robust and resilient applications. Everyone wins (customers, devs, SREs, etc.).

Is SRE the most inflated ego job title in tech?

oxff 4y ago

Software "Engineer" is (stolen valor from real world Engineers)

exdsq 4y ago

ML Engineer? Wait! No. My vote goes to AI Ethicist.

borplk 4y ago

No it's quite an accurate title and I don't think it's inflated. It's not really considered something prestigious.

trhway 4y ago
It is presented as prestigious in order to hire at least somebody into it. While, depending on place, work may be interesting the management usually is more rotten than say in dev.
thematrixturtle 4y ago
It's considered prestigious by other engineers. Outside engineering, not so much. At one point in my career I moved from a technical presales role to SRE. The engineers congratulated me on the promotion, while the sales people all thought it was a demotion. (And in terms of career progression it probably was.)
- tristor 4y ago
  > It's considered prestigious by other engineers. I'd love to see some evidence of that. I have never been in an organization where Ops folks and SREs are treated as if those roles are prestigious by other people in the engineering org. Generally they're treated like digital janitors, and assumed to be bad at software development. I've literally had an SWE /at work/ say to my face that "You're in Ops because you weren't smart enough to pass a code interview" because they were upset I had pointed out a flaw in their design and were essentially making an appeal to the nebulous authority of their title. SRE is definitely more prestigious than being in technical presales to other engineers, but that's because to other engineers any role in the sales org is not real engineering (even if it is), and to sales people anything in the engineering org is a demotion because it means you are joining "the basement people". Sales people aspire to becoming a CEO, not to building something that makes a mark on the world. Engineers want to build the thing, they don't care /how/ they have to go about doing it (whether that's being a founder/ceo or working in the basement).

dijit 4y ago

That's not the fault of people doing the work, that's what the industry is doing to us. I get increasingly irritated with the myth that 'DevOps' are any different than the sysadmins of 10 years ago. "But DevOps can code", yes, so could sysadmins, in fact, terraform, ansible, vagrant, saltstack, chef, puppet etc;etc;etc are all made by people who held the title of sysadmin when they were written. In fact even the term "DevOps" was originally from a conference, where the idea was that "we can do systems administration in an agile way" -- NOTHING to do with coding, everything to do with getting developers and sysadmins working closely together in an iterative fashion. I would personally be very happy being called a sysadmin, but doing so is career suicide, because we as an industry have decided that sysadmins are somehow braindead, and that you really need "SREs" or "DevOps" -- despite the fact that these are the same people. What gets my goat even more is that people hate on sysadmins because of corporate culture, echos of centralised IT organisations that said no to everything. But we're doing exactly the same thing with these new titles now. It's a joke. (This text, from yesterday: https://news.ycombinator.com/item?id=31194067 https://news.ycombinator.com/item?id=31194067 ) ——- I would be very happy to be called a sysadmin again, we can take some principles from the SRE book and that’s fine. This is increasingly annoying because oh can’t be called a “engineer” in Canada, it’s a protected title. I even wrote a ranty blog post about this a couple years ago, I will post it here later. http://blog.dijit.sh/devops-confusion-and-frustration http://blog.dijit.sh/devops-confusion-and-frustration

iaresee 4y ago
You can be called engineer in Canada. You can’t offer engineering services to the public without being licensed. Non-PEO licensed software engineers exist in large quantities in Canada without any issues. They provide services to a company, not the public.
prepend 4y ago
I think the difference is that there were (and still are) many sysadmins who don’t code. So the shift was that there was an expectation that all ops people could code. I don’t think it’s solely a Unix/windows thing, but I still work with windows admins who manually set up machines. Like they set up a vm in azure and then spend hours or days pushing buttons until it’s “ready.” For one vm. A person like this should not be in ops. They should be trained and improved to automate this by code. So the world is full of “there’s always been devops” because 30 years ago sysadmins were scripting out their stuff in shell scripts and whatnot. And also “we’re moving to devops” where people still manually do system tasks.

tristor 4y ago

The title might be inflated, and maybe the egos too (but that's true across engineering disciplines), but I can tell you the pay certainly isn't inflated. While I was in Operations, I on average was paid 1/2 of what an equivalent level SWE would get paid in most companies, this was typical across the industry, and I'm guessing still is. Because SRE came out of Ops, which came out of SysAdmin, there's a cultural expectation both by other engineers and by management that you are essentially a digital janitor, and if you can code it's only minimally so that you can write glue scripts, rather than being equally capable as an SWE. The reality is that most of my peers were /better/ developers than equal-level SWEs, because they had a stronger understanding of lower level systems and their interactions than SWEs who spent all their time working in abstractions. As another commenter notes, I would have been perfectly happy keeping the "SysAdmin" title my entire career, and while I held the title for awhile, it always grated on me when people were hired as DevOps Engineers (I would often tell managers "DevOps is a philosophy, not a job title."). At least SRE accurately describes the work in some abstract sense, you are an engineer and your primary duty is the reliability of the public facing site and its dependent backend services. Frankly, the amount of derision I see here and in other tech circles from SWEs against basically every other role in tech makes me think SWEs are the ones with the ego, for that matter.

pm90 4y ago
> Frankly, the amount of derision I see here and in other tech circles from SWEs against basically every other role in tech makes me think SWEs are the ones with the ego, for that matter. I can believe this. It’s especially funny when building a reliable system today requires a really basic understanding of few low level system concepts (eg graceful termination, signal handling, healthchecks, DNS) and most SWEs I work with simply refuse to learn these things.
- nickjj 4y ago
  > most SWEs I work with simply refuse to learn these things Are the SWEs over worked with unrealistic deadlines? Also how did the SRE present this information to them? I think both factors can drastically have an effect on the outcome. For example a small team who is already on the brink of being overburdened getting tossed a few links on Slack that says "please make sure you know about Kubernetes graceful shutdown timeouts and signals" with no other context is going to be met with resistance because now it feels like you're giving them another job. If they have no prior experience with that sort of thing it could take days to partially understand it. That's eating up time for their sprint, etc.. Alternatively, you could write a nice bit of documentation in private explaining the problem and why graceful shutdowns are a good thing, how it aligns with being able to deploy new versions of our apps, how they can create a better user experience for the apps they're building along with prepare anything you can to get as much information about your apps as possible (longest page responses, etc.), then spend a bit of time with your tech lead or someone who knows your applications well to iron out good values for all of your services (this assumes a worst case scenario where you don't have these metrics logged anywhere yet). Then wrap things up with a 5-10 min show / tell to share this knowledge with the devs so they have an awareness of it. In my opinion that maximizes everyone's time, the SRE doesn't even need to know much at all about the app's business domain too since it all boils down to how long an app might take to exit. Knowing a bit about the tech stack can be researched for the document you'll write too, such as mentioning how you can hook into the shutdown process of the app server to potentially execute code during a graceful shutdown, etc.. I've found that after all of that, it was embraced in a very positive way with devs now looking for ways to improve the app to better handle the app shutting down at unknown times without data loss and minimal user disruption. This is now a skill set the devs can take with them anywhere around having experience building robust and resilient applications. Everyone wins (customers, devs, SREs, etc.).