Scrum and Agile seem to be dying. I had a Product Owner and Scrum Master cert for years on my resume but i've dropped it from my current. Feels now like the ancient webmaster title of the mid 90s. Made for another timeline which is not more relevant.
DevOps is another sad story as it was a saner approach to get people skilled for both dev and ops but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Exactly. The field is already too complicated, you can learn a lot without learning literally everything.
Actually, no one learns literally everything. "DevOps" mean that developers should prioritize learning ops over learning deeper something else (because ultimately there are only 24 hours in a day). Which sounds crazy to me; it would be better if the team had experts on different things cooperating together, rather than everyone being mediocre at everything.
That said, companies love replaceable people, or at least they love to imagine that everyone is replaceable. So when everyone becomes DevSecOpsCloudAccountantJanitor, it feels like as long at they keep one such person in the company, they got everything covered.
I kindly disagree. In my experience, developers don't spend 24h a day learning new stuff. They spend their working hours mostly writing new code. Learning how to build and ship it correctly isn't a lot of effort, averaged over years of work.
My feeling is more that developers want to believe that they are the superstars, and they don't want to do the "lower job" that is devops. "I'm too good to learn how to not make a mess in the CMakeLists".
> DevSecOpsCloudAccountantJanitor
I think that "DevOps" has "dev" in it for a reason. It is very close to what the devs produce. I am not saying that developers should be sysadmins or accountants or janitors. Just that they should know how to build their shit.
> Learning how to build and ship it correctly isn't a lot of effort, averaged over years of work.
As someone who worked for years at a company that delivered tools in the devops space, I think you're overlooking the difference between someone who deploys apps to Kubernetes and someone who sets up and maintains kubernetes clusters on bare metal hardware that they procured.
The dev may understand a lot of things about kubernetes, but the devops person is doing a lot of things behind the scenes that the dev should never have to worry about.
As someone who has been in the "robot devops" space for like a decade now, I think with robot companies it becomes particularly acute because:
- Ops for cloud services and ops for deployed robots are very different beasts, so it's really two different teams that could both reasonably be "devops".
- Ops/tools for robot developers is different since you're often dealing with simulation environments (local, cloud) and also managing access to a more constrained pool of test hardware, all of which needs to be able to quickly recover and restore itself to factory state after developers or their code have done unspeakable things.
- Deployed units are often the worst of both worlds between multiple domains. You've got the big deployment assets of a data center but without the big data pipe; nothing is virtualized so you can't just throw away a node that goes bad; you're stuck supporting hardware snowflakes (here's a text file somewhere with the list of units that have bad CPU fans and need different frequency caps); it's like IOT but with the power and disk and observability requirements of a real server.
Plus there's the mess of "different audiences need different views of info about the robots in order to triage" and those lines are murky, and someone's always trying a new tool, and "ugh, the new thing is great for group A, but now I can't efficiently see Y, and the old tool was fine (for me)"
> IOT but with the power and disk and observability requirements of a real server
And the issue with the robot is usually none of the regular observability health metrics of a real server... but when it is... "where does that dashboard live again, and is it still working?"
> but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Titles like these always mean something different from company to company.
Even “product manager” has had different meanings at my different employers, some times with major consequences for people who got hired into those roles expecting to do one type of work and then being evaluated on different expectations.
For DevOps, there were a lot of unrealistic expectations from everyone who saw the word and assumed they knew what it meant. I saw a lot of engineering leaders come up with completely different expectations for DevOps roles, but when the chaos arrived most of them reduced the DevOps people into the responsible-for-everything people, which just burned people out.
I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
> I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
This depends on the org, but product managers I've worked with spend a lot of time speaking directly with users, particularly in B2B shops. Between speaking with customers and communicating product plans both upwards (to GMs/VPs/exec etc) and outwards (to your own team + external teams) you really shouldn't have a lot of time to build anything as a PM, even with AI.
Where "product manager" really started going off the rails was when enterprise agile achieved hockey stick level popularity as all of a sudden the "product owner" role wound up being in the "product manager" job family.
All of a sudden you had "product managers" inserted deep in the bowels of large systems, instead of focusing on big picture topics.
DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
Last team I was on was repsonsible for supporting and maintaining their product, with help from the SRE team. It means after-hours support for issues and (maybe) releases but I think this was the right way. You became the backstop and support resource for things like data center outages and DDOS attacks that were largely the responsiblity of the (much smaller than many places) SRE team. We also put devs very closely behind front-line customer facing staff where it made sense (ex: reporting & analytics - yes, platform - probably not). It made the devs better and they might try and deny it but I think most of them actually appreciated it. #YMMV
The issue I was facing in a previous life was the turnover. We had data scientists, DBA and many specialized roles stay pretty long, where devops moved away at about twice the rate, and work life balance was mentionned in many exit interviews.
I agree with you that it's extremely formative, and having devs involved basically from start to end of the service surface gives a lot of flexibility. The downside being that it requires a ton of different skills as well, and while people learn, many won't get comfortable with it even after months.
This makes it specially tough when people get called at 3 in the morning to deal with an emergency while they've already spent half the night sleep deprived from their kid puking all night. The worst part being that while people could understand wanting to skip turn one or two times, engineers with small kids will have enough going in their lives that most on-call instances land at a time they're busy dealing with more important matters.
> being in the war room when a data center goes under
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
Imagine managing a gitlab instances. You're doing it for years and have a stable environment. If one of the instance gets hammered by external traffic or one of your data center dies, will you call the gitlab devs to deal with it ?
Depending on the size of the deployment. (Not sure what you mean with "one of your data center" though) If it's just you, you deal with it. If you're running a bigger deployment, you likely have GitLab devs internally that will be reachable. Even bigger - you're likely to have access to upstream devs in the ultimate tier even with self hosting.
> DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles. Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
That's an org issue. For a given service dozens of roles will be involved, if devs are needed to do every single of them to care and be invested, there is a problem.
> [...] Only your developers can answer this question, not the ops team.
Yes. Those are questions that need an answer before a service is released, and the ops team need the veto power + sufficient means to escalate recurring issues in ways that will hurt the dev teams enough to make them care.
[−]lowbloodsugar · 2026-11-14 Sat 21:16 UTC ·
link
>DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
These are all good point, that I think aren't really related to having devs do operations.
Having engineers understand what makes a service resilient and easy to manage, as well as giving them incentives to produce high quality code doesn't require them to do SRE. In particular, being close enough to the SRE team, getting inputs when building the feature, detailed feedback and requests on live services, and the blame when shit hits the fan, are a more scalable way of doing it IMHO.
[−]lowbloodsugar · 2026-11-15 Sun 00:33 UTC ·
link
>Having engineers understand what makes a service resilient and easy to manage,
I don't believe engineers can understand this without experiencing it. A counter argument might be "football coaches don't need to have played", but the counter to that is "players need to have played". Why would being on call make you a better player? Personally, I think being the person watching the dashboards, in realtime, scraping the logs, in real time, watching how the contagion happens, in real time, gives insights that a next-day post mortem just doesn't. There are things I've learned only from hearing something on the conference call and then asking someone about it in chat. Watching a presentation on "Why 99% of people fell of our new bike" isn't nearly as useful as riding the fucking bike.
I've been on teams (briefly) where the ops team having an absolutely shit 48 hours was simply not on the dev teams radar, because they had more important things to worry about. That of course meant that when devs needed, e.g. a new host to try something, ops just dragged their feet, sometimes for months. Perhaps I've only seen dysfunctional companies in this regard. Or perhaps teams are made of humans, and splitting dev and ops is guaranteed to fail for any organization of more than 20 people? Like, sure, a startup of ten highly motivated people - maybe that works. Never done that myself: we've always run our own shit at the startups I've run/worked. Once that startup is 50 people, I think you're destined to fail with separate dev and ops.
Been paid for this over 40 years now. Done startups and FAANGs. But yes, the rewards better be fucking worth it, and the shifts better be reasonable.
So like, I'm not certain you're wrong. I don't think you can be wrong here. It's about what you're willing to do. Personally, I've done both ways, and if I started a company, I'd only hire people willing to support their shit with a pager. I'm not sure that matters for all businesses, but I'm not interested in starting, e.g. a mom-and-pop web hosting site for local businesses. If the service matters, devs are on call. So maybe I'm self selecting by the expected $ return.
Any developer who doesn't at least *understand* the ops side of the fence and has never spent time actually *doing* it, will make bad decisions along the way from an ops perspective. These are bad developers.
I see a stark difference between understanding how it works and doing it in a professional manner.
For instance I probably have a decent understanding of what our CS team deals with, the tools they use, the volume and overall content of the customer feedback and requests that are coming to us. But I don't sit at a CS desk every day for a few hours and process the tickets of the service I'm running.
You should at least be able to step in and do that job, however, if necessary. That's different than that being the most efficient use of your time, but it's something every good developer should be *capable* of doing.
Understanding anything is not binary, and evolves over time. Feeling like you understand something and then having at least some continuous hands-on experience are incomparable levels.
At the end, its just another part of your skillset with the general aim being the best / most experienced engineer to deliver best designed software for customer/company needs. There is no real seniority without being fully-versed in roughly everything that makes software stable and maintainable and delivering it. One cannot be had without the other.
DevOps should be a guiding principle for the organization, not a dedicated role. Every developer (or at least: every team) should be able to
- speak to production users
- ship to production
- monitor and learn from production usage
You don't need "devopsy" skills to do that, rather organizational structures that allow for incremental change. FWIW, deployments could still be a 2005-like upload via FTP, and the benefits of DevOps could still be reaped.
We’re seeing the same thing with QA. I guess developers can QA their own deliverables.
Leaving out the key fact that the vast majority of developers have no interest in testing stuff. And thus you end up “testing in prod” like with Microsoft projects.
It’s not a coincidence Microsoft’s software quality has collapsed since they’ve eliminated dedicated QA/SDET roles.
A programmer has to be able to demonstrate that his program has the required properties. If this comes as an afterthought, it is all but certain that he won't be able to meet this obligation: only if he allows this obligation to influence his design, there is hope he can meet it. Pure a posteriori verification denies you that wholesome influence and is therefore putting the cart before the horse, but that is exactly what happens in the software houses where "programming" and "quality assurance" are done by different groups. [Needless to say, those houses deliver without warranty.]
While I agree with this, in a lot of software there's more to verify than just being correct. Unless there's a separate and rigid UI/UX spec then there's also matter of things being intuitive to use etc. which may vary from person to person and the one making the thing might not have the same sensibilities as the users.
Why does the ability to interact with users, being able to test code, profile/debug code, and actually manage your deployed software imply you're a master of none? Too many developers act like it's a good state of affairs that they just get locked in the basement to grind the code. And now that we have tools that can grind code for you, they're finding out why that wasn't a good state of affairs for them.
The answer is master all of them, not none of them.
Most people aren't particularly good beyond 1/3 of those domains. It's delusional to expect everyone to be Superman even though that idea is amazing in a vacuum.
Everyone now needs to be full stack and experienced with dev ops , cicd too. Maybe you’ll also be forward deployed so you can gather client requirements, implement them, test, and deploy the whole project.
I’m seeing contracts with twice as many required skills for about half of what I was making in 2019.
Wait until you hear that some employers might expect that you take a car or public transportation to the office, all by yourselves. I mean, come on, you're not a mechanical engineer or public transportation policy expert, how should you do that. Driving a car or taking a bus are skills that cannot be acquired in a couple of hours. Those are crafts that rely on wisdom of generations, passed on only from father to son. Just like taking care that the new image compression that you've implemented for your company's "Not Hotdog" app doesn't break production. How dare they asking you to write an e2e test that plugs into the existing test runner, and add the creation of required artifacts to the existing CI/CD pipeline.
If someone expects a non specialized developer to create a CI/CD pipeline for a brownfield project from scratch, or implement a test strategy including runner infra etc., then that's not DevOps. It's just stupid.
Once you write software that is run in places other than your computer by people other than you, you have the right and the duty to speak to those people, to look into those places, and to push updates in small increments once you've learned something valuable from either of the two sources. "You" can be a small team of close collaborators, so not every developer has to speak to users, and not all developers need to push to prod or look into the Grafana every now or then. It's just that those responsibilities should not be gated into remote departments.
Infrastructure is still provided and maintained by Ops. That's exactly the point of my critique: giving Devs access and responsibilities is no excuse to dump the whole Ops department. Managers shouldn't give someone a DevOps-title and think they get 2 for 1.
Similarly, asking Devs to write and maintain proper test automation for their services is the bare minimum - scraping centralized QA is still a bad call, though. Somebody must build and run test infra, set and enforce standards, aggregate data, track regressions, keep the full picture etc. - but they shouldn't block incremental deployments for days.
Extremely narrow focus makes one visibly worse off since topics in real world are never so narrow and to deliver anything complex in any engineering one has to understand cascading consequences of every complex decision. And what is software than series of complex decisions, usually about how to handle and secure data for backend and talk to user in frontend.
Without understanding how prod is actually used, monitored, how things are fixed etc its almost impossible to design, deliver and maintain any software worth its salt in any company.
Come to interview with such attitudes and if you ever get hired it will be for lowest pay scale. Given current market for juniors it would probably not be nice for you.
It's sad that people still think DevOps was about teaching people "dev and ops skills". There isn't even such a thing as "ops skills". Ops stands for Operations - as in Operations Management, a job that has nothing to do with servers (it's a job focused on ensuring business continuity in any industry). The term "Operations" got associated with servers and server commands because the department that Systems Administrators worked in was called the "IT Operations" department, aka, ensuring the business continuity of the Information Technology department. All of this happened because the entire industry spontaneously became collectively ashamed of the term "Systems Administrator" and "sysadmin". But they still wanted a way to refer to "the server people" and "what server people do", so they started saying "ops".
The "Ops" in DevOps was intended to mean the department itself, not the tasks they performed. The idea that devs should be learning or doing Systems Administration is the same as a building architect learning/doing concrete pours. They should know about concrete and the pouring/curing process, but they don't (and shouldn't) be pouring and smoothing the concrete themselves.
You know it's ironic that people think that scrum and agile is dying and at the same time everyone's dog and their uncle is working in sprints, or using a Kanban board, etc. WTF are these people doing I wonder??? And why???
I think both are true. Agile/SCRUM as these vaunted “hire a coach and certified scrum masters and your process blockers go away” org-wide religions are on the wane.
But they left behind a few practices that were easy to adopt and lots of people liked (whether that makes them “the good parts of agile” or “lazy process theater” depends on who you ask). Sprints, boards, paying attention to velocity, and so on.
DevOps is another sad story as it was a saner approach to get people skilled for both dev and ops but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
I'm asking what op believes is accidental complexity. If it was reducible we would've surely done so by now?
Actually, no one learns literally everything. "DevOps" mean that developers should prioritize learning ops over learning deeper something else (because ultimately there are only 24 hours in a day). Which sounds crazy to me; it would be better if the team had experts on different things cooperating together, rather than everyone being mediocre at everything.
That said, companies love replaceable people, or at least they love to imagine that everyone is replaceable. So when everyone becomes DevSecOpsCloudAccountantJanitor, it feels like as long at they keep one such person in the company, they got everything covered.
My feeling is more that developers want to believe that they are the superstars, and they don't want to do the "lower job" that is devops. "I'm too good to learn how to not make a mess in the CMakeLists".
> DevSecOpsCloudAccountantJanitor
I think that "DevOps" has "dev" in it for a reason. It is very close to what the devs produce. I am not saying that developers should be sysadmins or accountants or janitors. Just that they should know how to build their shit.
As someone who worked for years at a company that delivered tools in the devops space, I think you're overlooking the difference between someone who deploys apps to Kubernetes and someone who sets up and maintains kubernetes clusters on bare metal hardware that they procured.
The dev may understand a lot of things about kubernetes, but the devops person is doing a lot of things behind the scenes that the dev should never have to worry about.
- Ops for cloud services and ops for deployed robots are very different beasts, so it's really two different teams that could both reasonably be "devops".
- Ops/tools for robot developers is different since you're often dealing with simulation environments (local, cloud) and also managing access to a more constrained pool of test hardware, all of which needs to be able to quickly recover and restore itself to factory state after developers or their code have done unspeakable things.
- Deployed units are often the worst of both worlds between multiple domains. You've got the big deployment assets of a data center but without the big data pipe; nothing is virtualized so you can't just throw away a node that goes bad; you're stuck supporting hardware snowflakes (here's a text file somewhere with the list of units that have bad CPU fans and need different frequency caps); it's like IOT but with the power and disk and observability requirements of a real server.
> IOT but with the power and disk and observability requirements of a real server
And the issue with the robot is usually none of the regular observability health metrics of a real server... but when it is... "where does that dashboard live again, and is it still working?"
Titles like these always mean something different from company to company.
Even “product manager” has had different meanings at my different employers, some times with major consequences for people who got hired into those roles expecting to do one type of work and then being evaluated on different expectations.
For DevOps, there were a lot of unrealistic expectations from everyone who saw the word and assumed they knew what it meant. I saw a lot of engineering leaders come up with completely different expectations for DevOps roles, but when the chaos arrived most of them reduced the DevOps people into the responsible-for-everything people, which just burned people out.
This depends on the org, but product managers I've worked with spend a lot of time speaking directly with users, particularly in B2B shops. Between speaking with customers and communicating product plans both upwards (to GMs/VPs/exec etc) and outwards (to your own team + external teams) you really shouldn't have a lot of time to build anything as a PM, even with AI.
All of a sudden you had "product managers" inserted deep in the bowels of large systems, instead of focusing on big picture topics.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
The issue I was facing in a previous life was the turnover. We had data scientists, DBA and many specialized roles stay pretty long, where devops moved away at about twice the rate, and work life balance was mentionned in many exit interviews.
I agree with you that it's extremely formative, and having devs involved basically from start to end of the service surface gives a lot of flexibility. The downside being that it requires a ton of different skills as well, and while people learn, many won't get comfortable with it even after months.
This makes it specially tough when people get called at 3 in the morning to deal with an emergency while they've already spent half the night sleep deprived from their kid puking all night. The worst part being that while people could understand wanting to skip turn one or two times, engineers with small kids will have enough going in their lives that most on-call instances land at a time they're busy dealing with more important matters.
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
So... Yes, sometimes you will.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
That's an org issue. For a given service dozens of roles will be involved, if devs are needed to do every single of them to care and be invested, there is a problem.
> [...] Only your developers can answer this question, not the ops team.
Yes. Those are questions that need an answer before a service is released, and the ops team need the veto power + sufficient means to escalate recurring issues in ways that will hurt the dev teams enough to make them care.
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
Having engineers understand what makes a service resilient and easy to manage, as well as giving them incentives to produce high quality code doesn't require them to do SRE. In particular, being close enough to the SRE team, getting inputs when building the feature, detailed feedback and requests on live services, and the blame when shit hits the fan, are a more scalable way of doing it IMHO.
I don't believe engineers can understand this without experiencing it. A counter argument might be "football coaches don't need to have played", but the counter to that is "players need to have played". Why would being on call make you a better player? Personally, I think being the person watching the dashboards, in realtime, scraping the logs, in real time, watching how the contagion happens, in real time, gives insights that a next-day post mortem just doesn't. There are things I've learned only from hearing something on the conference call and then asking someone about it in chat. Watching a presentation on "Why 99% of people fell of our new bike" isn't nearly as useful as riding the fucking bike.
I've been on teams (briefly) where the ops team having an absolutely shit 48 hours was simply not on the dev teams radar, because they had more important things to worry about. That of course meant that when devs needed, e.g. a new host to try something, ops just dragged their feet, sometimes for months. Perhaps I've only seen dysfunctional companies in this regard. Or perhaps teams are made of humans, and splitting dev and ops is guaranteed to fail for any organization of more than 20 people? Like, sure, a startup of ten highly motivated people - maybe that works. Never done that myself: we've always run our own shit at the startups I've run/worked. Once that startup is 50 people, I think you're destined to fail with separate dev and ops.
Been paid for this over 40 years now. Done startups and FAANGs. But yes, the rewards better be fucking worth it, and the shifts better be reasonable.
So like, I'm not certain you're wrong. I don't think you can be wrong here. It's about what you're willing to do. Personally, I've done both ways, and if I started a company, I'd only hire people willing to support their shit with a pager. I'm not sure that matters for all businesses, but I'm not interested in starting, e.g. a mom-and-pop web hosting site for local businesses. If the service matters, devs are on call. So maybe I'm self selecting by the expected $ return.
For instance I probably have a decent understanding of what our CS team deals with, the tools they use, the volume and overall content of the customer feedback and requests that are coming to us. But I don't sit at a CS desk every day for a few hours and process the tickets of the service I'm running.
At the end, its just another part of your skillset with the general aim being the best / most experienced engineer to deliver best designed software for customer/company needs. There is no real seniority without being fully-versed in roughly everything that makes software stable and maintainable and delivering it. One cannot be had without the other.
- speak to production users
- ship to production
- monitor and learn from production usage
You don't need "devopsy" skills to do that, rather organizational structures that allow for incremental change. FWIW, deployments could still be a 2005-like upload via FTP, and the benefits of DevOps could still be reaped.
We’re seeing the same thing with QA. I guess developers can QA their own deliverables.
Leaving out the key fact that the vast majority of developers have no interest in testing stuff. And thus you end up “testing in prod” like with Microsoft projects.
It’s not a coincidence Microsoft’s software quality has collapsed since they’ve eliminated dedicated QA/SDET roles.
https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD130...
Why does the ability to interact with users, being able to test code, profile/debug code, and actually manage your deployed software imply you're a master of none? Too many developers act like it's a good state of affairs that they just get locked in the basement to grind the code. And now that we have tools that can grind code for you, they're finding out why that wasn't a good state of affairs for them.
The answer is master all of them, not none of them.
I’m seeing contracts with twice as many required skills for about half of what I was making in 2019.
If someone expects a non specialized developer to create a CI/CD pipeline for a brownfield project from scratch, or implement a test strategy including runner infra etc., then that's not DevOps. It's just stupid.
Once you write software that is run in places other than your computer by people other than you, you have the right and the duty to speak to those people, to look into those places, and to push updates in small increments once you've learned something valuable from either of the two sources. "You" can be a small team of close collaborators, so not every developer has to speak to users, and not all developers need to push to prod or look into the Grafana every now or then. It's just that those responsibilities should not be gated into remote departments.
Infrastructure is still provided and maintained by Ops. That's exactly the point of my critique: giving Devs access and responsibilities is no excuse to dump the whole Ops department. Managers shouldn't give someone a DevOps-title and think they get 2 for 1.
Similarly, asking Devs to write and maintain proper test automation for their services is the bare minimum - scraping centralized QA is still a bad call, though. Somebody must build and run test infra, set and enforce standards, aggregate data, track regressions, keep the full picture etc. - but they shouldn't block incremental deployments for days.
Nothing makes you take testing your code more seriously than having to respond to an outage caused by a bug code you wrote.
Extremely narrow focus makes one visibly worse off since topics in real world are never so narrow and to deliver anything complex in any engineering one has to understand cascading consequences of every complex decision. And what is software than series of complex decisions, usually about how to handle and secure data for backend and talk to user in frontend.
Without understanding how prod is actually used, monitored, how things are fixed etc its almost impossible to design, deliver and maintain any software worth its salt in any company.
Come to interview with such attitudes and if you ever get hired it will be for lowest pay scale. Given current market for juniors it would probably not be nice for you.
The way I've always phrased it is that if a company has "DevOps" teams or titles, they're not doing DevOps by definition
The "Ops" in DevOps was intended to mean the department itself, not the tasks they performed. The idea that devs should be learning or doing Systems Administration is the same as a building architect learning/doing concrete pours. They should know about concrete and the pouring/curing process, but they don't (and shouldn't) be pouring and smoothing the concrete themselves.
But they left behind a few practices that were easy to adopt and lots of people liked (whether that makes them “the good parts of agile” or “lazy process theater” depends on who you ask). Sprints, boards, paying attention to velocity, and so on.