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.
- 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