I feel this so much and it hurts. 3 yrs of SRE roles has made me go from loving work and problem solving – as a dev prior to the SRE work – to hating work and wanting to quit or get laid off on the best days, and wanting to die on the bad ones. Pro tip to devs: do not take a SRE role, even for the additional pay.
Please forgive me for the “devops” tag. I felt this so much, and it’s extremely annoying to see in the wild. Heck, my own company has a separate “SRE/Ops” team that just does ops. They pride themselves in the fact that they don’t write code and they “hack stuff together with bash”. While I sit across the hallway doing actual SRE work in the Kubernetes team.
As annoying as it is to see technical terms lose their meaning, I’m sure those people don’t deserve to be called monkeys. It’s OK to be content with doing only ops.
I don’t know the author or GP commenter, but I’ve always seen the “$x monkey” term as “someone is happy doing $x in their role and isn’t concerned with outside issues” - e.g. in Jonathon Coulton’s Code Monkey: https://www.youtube.com/watch?v=v4Wy7gRGgeA
I don’t think there’s necessarily a negative connotation associated - but as I said I don’t know the author of the article, and their reference does seem to be less enthralled by someone who has chosen/is happy to specialise in ops (aka what we used to call sysadmin) so maybe my read is wrong and it was meant to be disparaging?
I’m not saying “doing $x makes the person happy regardless of other factors” I’m saying that $x is what they are happy to (read: want to) focus on in their work.
But he hates his job too. Anyway, it’s possible your meaning is the generally accepted one, just that using the song as an example isn’t backing it up.
I don’t think I can agree with that assessment, I think what you’re attributing to “hating his job” is more like frustration at not being appreciated for what he does.
This is what Jonathon said when he first released the song:
Yay, monkeys. This is not autobiographical, but I did indeed used to have a job writing software. VB! MS SQL! I affectionately referred to myself and my co-developers as code monkeys, especially when a client asked me a question that I didn’t want to answer (“What do I know? I’m just a code monkey.”).
I mean, I think it’s pretty clear from the lyrics that he hates his job - he pretty much straight-up says that he’s only there because of the receptionist (I think?) he’s in love with, and who seems to be uninterested in him. “Code Monkey have every reason to get out this place […] This job fulfilling in creative way - what a load of crap.”
But perhaps he does love coding - his horrible job aside.
(This is something I reflected a bit about in a particularly soul-crushing job, three jobs ago: I loved coding, but at that point I felt like I hated having it be my job.)
I am perfectly happy describing a job as “Rack monkey.”
And then you can describe a person by their job. “Administrator” “Devops guy” “Dev.” But everybody of course needs to understand that a person’s job does not define a person, and every job needs to be filled by somebody.
Some of these jobs of course are lower paid, partly because the gap between a competent professional and inexperienced intern can be just a few weeks of training.
Nobody is being called a monkey. When the post says “people who basically were ops monkeys.” that describes people’s preferred job, not the person.
This is absolutely a thing. I had to rework the title at a prior job in collaboration with the CTO in order to ensure that the … clickops… people wouldn’t be applying.
We just called it like… software engineer, infrastructure… or something. I don’t recollect the details. But “SRE” is not a workable title at this point. Much like “Devops”.
I think this is just an extension of the buzzword-itis our industry seems to be forever saddled with.
I don’t actually recall the last time I saw anyone use the term “devops” the way it was originally intended (i.e. infrastructure as code, using generally-accepted development practices to approach operations, etc) - it’s essentially been coopted (I think largely by HR/management types) to mean “we want our developers to understand enough Bash and AWS console to make something kinda work”.
The dangerous part to me, with the definition of SRE in the article (ops who also creates new programs) is that you’re relying on the speaker’s intention to distinguish what you mean, from the plethora of “full stack code ninja” that will happily claim to be “expert” across domains from <insert graphics editor of your choice> all the way to server-side kernel hacking, and generally ends up being a jack of all trades, master of none.
I’m not saying it’s impossible for a single person to be very good at all the things that covers. I’m just saying that it’s statistically unlikely that most who say they are experts across that whole range, actually are.
I’m not saying people can’t be good at more than one thing. I wouldn’t use the term SRE myself but most of my work falls roughly into the description the author uses. But the moment you try to codify (only a small pun intended) some idea of complimentary tech skills behind a term, it’s almost guaranteed to get used and abused to the point of being meaningless.
I’m also not saying there isn’t a place for a jack-of-all-trades types. But as your team size increases, the appeal of that skillset rapidly decreases IMO. Having 10 people who have shallow knowledge of everything is nowhere near as useful or productive as 6 really great backend-focused developers, a UI/FE dev, a sysadmin, a tester and one jack-of-all-trades.
It’s helpful to have some people who can step into a number of roles to help out. It’s not helpful to be completely reliant on people with shallow-to-medium depth knowledge/experience of everything.
This is a fascinating perspective because it’s about an emergent property of SREs rather than a definitional property. SREs never had to generalize to full-stack development, but were forced to do it as the job market went sideways over the past decade.
To me, SRE is fundamentally about systems administration without developers. A common test of this is that an SRE team should be able to classify its owned components into three bins: those actively developed by another team, those developed by SREs in collaboration with support from other teams, and those developed solely by the SREs themselves. Crucially, an SRE organization isn’t healthy unless any component in the first bin can be disowned by the organization and returned back to its active developer team. This is a systems-first way of computing; the stability of the system is more important than the ability of developers to mutate it.
In a smaller organization, I currently ask my SRE team to: (1) deliver the stack from k8s downwards to the broader engineering team; (2) make the end user experience known throughout the organization; (3) ensure that production can always be updated; (4) be a mentor to the organization on reliability best practices; (5) make cloud service provider costs known throughout the organization.
It’s a complex role that requires specialized technical expertise, social and organizational skill, and the ability to earn significant trust given the security and reliability implications. It isn’t the role as originally defined by Google - so I guess I’m also guilty of abusing the SRE title - but it’s a combination of abilities with a lot of leverage and a lot of impact: essentially the foundation the product sits atop and core operational loop.
This is the mixture I’ve landed at trying to balance “dev teams own their services (at least until they get boringly stable)”, “someone needs to be the k8s expert”, and “someone needs to holistically report end-user experience regardless of service boundaries.”
I think “SRE” probably was a coherent and useful concept inside Google, and probably could also have been coherent inside other similar-size companies. But it became useless the moment the SRE book was published and people started evangelizing the concept to the world at large.
This happens with a lot of practices at gigantic tech companies. They work differently! They have to! And this applies to both their technical and their organizational choices. At a company like Google, you can have people ultra-specialized into the exact precise role described in the linked post. In fact, at Google you can have more people in this ultra-specialized role than there are employees, total, at most other companies (if i had to guess I’d guess Google probably has at least an order of magnitude more SREs than the total employee count of the company I work for).
But this also creates a problem when someone whose experience is at BigTech leaves that world. And this is a recurring problem I’ve seen when working with ex-Googlers (and ex-Facebookers, etc. etc.): they go to work at a company with, say, a few dozen people total on the software dev team and start trying to apply tools and techniques and practices that at BigCo were supported by teams of hundreds of people dedicated just to that individual thing. Plus, a lot of the ultra-specialized BigCo stuff is also optimized specifically to solve problems you only have, or only need to solve in this sort of way, when you are already a BigCo.
This isn’t true of everyone, of course, but that inability to “scale down” when no longer working at BigMcLargeHugeOMGCorp is common enough that it’s made me wary of working with people who’ve spent too much time in that world, and has made me look out for warning signs that someone has over-adapted to that niche and now cannot thrive outside of it.
(I feel fortunate sometimes that my “big” tech company experience was at Mozilla, and ended nearly ten years ago now, because Mozilla was not focused, as a company, on being a huge-scale web operator and I was there before a bunch of practices from companies that are focused on that escaped containment)
Business will always consume, digest and turn to shit every concept it comes into contact with. So something that may at first have been a useful shibboleth loses that usefulness.
Nothing described in this article is practical or a sane way to set stuff up. At most scales I see good companies (to which I would count us) try to live the principle of: «developers run their own services, platform enables them maximally to do so» but that may be too cutting edge for the majority as much as stuff like CD still is as well.
I feel this so much and it hurts. 3 yrs of SRE roles has made me go from loving work and problem solving – as a dev prior to the SRE work – to hating work and wanting to quit or get laid off on the best days, and wanting to die on the bad ones. Pro tip to devs: do not take a SRE role, even for the additional pay.
Please forgive me for the “devops” tag. I felt this so much, and it’s extremely annoying to see in the wild. Heck, my own company has a separate “SRE/Ops” team that just does ops. They pride themselves in the fact that they don’t write code and they “hack stuff together with bash”. While I sit across the hallway doing actual SRE work in the Kubernetes team.
As annoying as it is to see technical terms lose their meaning, I’m sure those people don’t deserve to be called monkeys. It’s OK to be content with doing only ops.
Yes, you’re right. I kinda just borrowed the term from the article, but yes, nobody deserves to be called monkeys for their work. I’ll edit that out.
I don’t know the author or GP commenter, but I’ve always seen the “$x monkey” term as “someone is happy doing $x in their role and isn’t concerned with outside issues” - e.g. in Jonathon Coulton’s Code Monkey: https://www.youtube.com/watch?v=v4Wy7gRGgeA
I don’t think there’s necessarily a negative connotation associated - but as I said I don’t know the author of the article, and their reference does seem to be less enthralled by someone who has chosen/is happy to specialise in ops (aka what we used to call sysadmin) so maybe my read is wrong and it was meant to be disparaging?
The titular developer in Coulton’s song is anything but happy…
I think you’ve misunderstood what I was saying.
I’m not saying “doing $x makes the person happy regardless of other factors” I’m saying that $x is what they are happy to (read: want to) focus on in their work.
But he hates his job too. Anyway, it’s possible your meaning is the generally accepted one, just that using the song as an example isn’t backing it up.
I don’t think I can agree with that assessment, I think what you’re attributing to “hating his job” is more like frustration at not being appreciated for what he does.
This is what Jonathon said when he first released the song:
https://www.jonathancoulton.com/2006/04/14/thing-a-week-29-code-monkey/
I mean, I think it’s pretty clear from the lyrics that he hates his job - he pretty much straight-up says that he’s only there because of the receptionist (I think?) he’s in love with, and who seems to be uninterested in him. “Code Monkey have every reason to get out this place […] This job fulfilling in creative way - what a load of crap.”
But perhaps he does love coding - his horrible job aside.
(This is something I reflected a bit about in a particularly soul-crushing job, three jobs ago: I loved coding, but at that point I felt like I hated having it be my job.)
I am perfectly happy describing a job as “Rack monkey.”
And then you can describe a person by their job. “Administrator” “Devops guy” “Dev.” But everybody of course needs to understand that a person’s job does not define a person, and every job needs to be filled by somebody.
Some of these jobs of course are lower paid, partly because the gap between a competent professional and inexperienced intern can be just a few weeks of training.
Nobody is being called a monkey. When the post says “people who basically were ops monkeys.” that describes people’s preferred job, not the person.
This is absolutely a thing. I had to rework the title at a prior job in collaboration with the CTO in order to ensure that the … clickops… people wouldn’t be applying.
We just called it like… software engineer, infrastructure… or something. I don’t recollect the details. But “SRE” is not a workable title at this point. Much like “Devops”.
gack.
I think this is just an extension of the buzzword-itis our industry seems to be forever saddled with.
I don’t actually recall the last time I saw anyone use the term “devops” the way it was originally intended (i.e. infrastructure as code, using generally-accepted development practices to approach operations, etc) - it’s essentially been coopted (I think largely by HR/management types) to mean “we want our developers to understand enough Bash and AWS console to make something kinda work”.
The dangerous part to me, with the definition of SRE in the article (ops who also creates new programs) is that you’re relying on the speaker’s intention to distinguish what you mean, from the plethora of “full stack code ninja” that will happily claim to be “expert” across domains from <insert graphics editor of your choice> all the way to server-side kernel hacking, and generally ends up being a jack of all trades, master of none.
I’m not saying it’s impossible for a single person to be very good at all the things that covers. I’m just saying that it’s statistically unlikely that most who say they are experts across that whole range, actually are.
I’m not saying people can’t be good at more than one thing. I wouldn’t use the term SRE myself but most of my work falls roughly into the description the author uses. But the moment you try to codify (only a small pun intended) some idea of complimentary tech skills behind a term, it’s almost guaranteed to get used and abused to the point of being meaningless.
I’m also not saying there isn’t a place for a jack-of-all-trades types. But as your team size increases, the appeal of that skillset rapidly decreases IMO. Having 10 people who have shallow knowledge of everything is nowhere near as useful or productive as 6 really great backend-focused developers, a UI/FE dev, a sysadmin, a tester and one jack-of-all-trades.
It’s helpful to have some people who can step into a number of roles to help out. It’s not helpful to be completely reliant on people with shallow-to-medium depth knowledge/experience of everything.
This is a fascinating perspective because it’s about an emergent property of SREs rather than a definitional property. SREs never had to generalize to full-stack development, but were forced to do it as the job market went sideways over the past decade.
To me, SRE is fundamentally about systems administration without developers. A common test of this is that an SRE team should be able to classify its owned components into three bins: those actively developed by another team, those developed by SREs in collaboration with support from other teams, and those developed solely by the SREs themselves. Crucially, an SRE organization isn’t healthy unless any component in the first bin can be disowned by the organization and returned back to its active developer team. This is a systems-first way of computing; the stability of the system is more important than the ability of developers to mutate it.
In a smaller organization, I currently ask my SRE team to: (1) deliver the stack from k8s downwards to the broader engineering team; (2) make the end user experience known throughout the organization; (3) ensure that production can always be updated; (4) be a mentor to the organization on reliability best practices; (5) make cloud service provider costs known throughout the organization.
It’s a complex role that requires specialized technical expertise, social and organizational skill, and the ability to earn significant trust given the security and reliability implications. It isn’t the role as originally defined by Google - so I guess I’m also guilty of abusing the SRE title - but it’s a combination of abilities with a lot of leverage and a lot of impact: essentially the foundation the product sits atop and core operational loop.
This is the mixture I’ve landed at trying to balance “dev teams own their services (at least until they get boringly stable)”, “someone needs to be the k8s expert”, and “someone needs to holistically report end-user experience regardless of service boundaries.”
I think “SRE” probably was a coherent and useful concept inside Google, and probably could also have been coherent inside other similar-size companies. But it became useless the moment the SRE book was published and people started evangelizing the concept to the world at large.
This happens with a lot of practices at gigantic tech companies. They work differently! They have to! And this applies to both their technical and their organizational choices. At a company like Google, you can have people ultra-specialized into the exact precise role described in the linked post. In fact, at Google you can have more people in this ultra-specialized role than there are employees, total, at most other companies (if i had to guess I’d guess Google probably has at least an order of magnitude more SREs than the total employee count of the company I work for).
But this also creates a problem when someone whose experience is at BigTech leaves that world. And this is a recurring problem I’ve seen when working with ex-Googlers (and ex-Facebookers, etc. etc.): they go to work at a company with, say, a few dozen people total on the software dev team and start trying to apply tools and techniques and practices that at BigCo were supported by teams of hundreds of people dedicated just to that individual thing. Plus, a lot of the ultra-specialized BigCo stuff is also optimized specifically to solve problems you only have, or only need to solve in this sort of way, when you are already a BigCo.
This isn’t true of everyone, of course, but that inability to “scale down” when no longer working at BigMcLargeHugeOMGCorp is common enough that it’s made me wary of working with people who’ve spent too much time in that world, and has made me look out for warning signs that someone has over-adapted to that niche and now cannot thrive outside of it.
(I feel fortunate sometimes that my “big” tech company experience was at Mozilla, and ended nearly ten years ago now, because Mozilla was not focused, as a company, on being a huge-scale web operator and I was there before a bunch of practices from companies that are focused on that escaped containment)
Business will always consume, digest and turn to shit every concept it comes into contact with. So something that may at first have been a useful shibboleth loses that usefulness.
Nothing described in this article is practical or a sane way to set stuff up. At most scales I see good companies (to which I would count us) try to live the principle of: «developers run their own services, platform enables them maximally to do so» but that may be too cutting edge for the majority as much as stuff like CD still is as well.
[Comment removed by author]