DevOps !== Software developer.

What do we think?

There's that wave of "infrastructure as code" - which is cool, but the non-infra code I've seen DevOps write doesn't smell like it's come from a seasoned developer (more scripts than "code").

Open to changing my mind x

You have a separate devops?

well, yes. that's why there's two different names.

What's the difference between scripts and code? But I'm all for people diversifying their skill set. And besides, half the code in any company probably wasn't written by a seasoned developer. A lot of people are little more than trained monkeys.

Frontend development isn't software development either, it's just drawing pictures programmatically.

Glorified sysadmin?

@electrineer to be fair, most of my uni lecturers were amazed when I actually managed to get window resizing working correctly. I made like, a full bidmas calculator and a phase field transition simulation, some other stuff too. Every time, they could resize the window/change the aspect ratio and it worked and they were extatic. For the phase field stuff that was one afternoon, vs 3 months getting the simulation working correctly.

Drawing is hard, even if you're telling a computer how to do it.

All devops I know were developers first

Dev != Devops, Ops != Devops but Dev + Ops == DevOps.

Three examples:
1. Dev chooses to use Sql in his new feature. So Ops now has to support A new SQL server deploy. Idle Server Costs go up.
2. Ops installed a WAF on the infrastructure. Dev used Websockets in old feature. WAF blocks. Feature breaks in production. Lost revenue, and high costs to recode the feature.
3. Dev/Ops/Devops has to figure out why a specific kubernetes cluster costs went up by 400% in the last week. Again: costs.

Bad arch costs money. Bad coding costs money. Breaks in production costs money. Who takes responsibility to fix? Who takes responsibility to prevent?
Devops.

Sometimes DevOps are just Ops under another name. They have no idea what the Devs are doing, or what effects the code has before it gets deployed. They react to code changes.
Real Devops should know how the code works - and help shape the code/arch, in order to improve Ops And Dev work, in a proactive methods.

@bigmonsterlover well now I wanna hear it

As far as I'm concerned. DevOps is not a job position but a system administration approach.

Either you run a standard setup, where you have Devs doing the software and you have Ops doing the Operations

Or you're running a DevOps setup, so your Devs also manage your Operations themselves.

Advantage of the first system is that Devs don't need high seniority level, they just do their small piece of the work, and if they need something done on the Ops side, they delegate to an Ops person

Advantage of the second system is that if you have Devs capable of doing Ops, they don't need to wait up for another person to do stuff like setup databases, wait for accesses to systems, explain how they need their Kubernates set-up and so on. You get the Devs to do that, because they also have objectively the best understanding of the system they are designing and managing.

I don't care what recruiters tell you, DevOps is not a job position and you don't "Hire DevOps Engineers"...

@bigmonsterlover
Should have a rant of its own.
But yes. The idea is to isolate those "ooga booga" devs by defining a good framework, and setting some limits, and limitations.

I once gave one of the morons a simple limit: "pass the boolean through the generic call, and change the logic in this class to handle the two cases". Probably 2 hours for me.
The moron took 3 days, and I found him making changes the the framework for some bizzare reason.... sat down with him for some "corrective peer programming".

There should be a separation of concerns, yes. DevOps is a specialized role. Role / job description doesn't specify a qualification, though.

E.g. I've seen senior devs getting fired on my management recommendation because they *sucked* at their job.

DevOps should know development and have development skills. It's an essential requirement, cause they need the mindset and the experience from developing on their own.

DevOps is mostly a different approach to the "classic" administration job, because "classic" administration cannot keep up with the workload that's required for most setups nowadays. Not a microservice thing by the way, rather a "shit becomes increasingly complex and solutions require far more resources" thingamabob. You cannot orchestrate a plethora of containers or virtual machines and their hypervisors via "mouse clicking"... To put it out wrong, but simply enough to get the message across.

Another reason why DevOps are needed is because (some) devs are inherently stupid. I still whack sometimes Devs ... Because they waste a plethora of time.

My favorite game is: Does the Dev *understand* and *use* it's IDE?

People changing Doc comments manually instead of auto generating... Devs doing manual linting, then bitching that the PR got auto rejected by the CI... People claiming they need XY time cause refactoring is so hard... During pair programming realization they either do not use the refactoring tools of the IDE or they do it in a completely moronic way.

(Eg. when you need to rename 1 to 2, c2 to 3, 3 gets deleted... It should be obvious you start by deleting 3… then rename 2 to 3, then 1 to 2. Some devs don't get the obvious solution. Yeah. Hurts. I know.)

Stuff like that occurs once a week at minimum. Best answer to the "Why?": I don't have time for that.

Which is even more stupid, as they would have more time if they fixed their shit. DevOps are 1st level for these cases and need to understand developer workflows for that.

No matter what you believe, it's up to the management to make the distinction.

If they say you have to do DevOps as a Software developer, then u ain't got no options.

@ostream software craftsman 🤔

I'd love to have someone configure Webpack and Docker on my behalf!

Everytime I struggle with these kind of tools, I keep thinking "this isn't front-end development, I shouldn't have to do this."

In a recent company, they hired "DevOps engineers" (isn't DevOps supposed to be a mindset / culture, not a job description?) and I thought, finally someone's going to do the dirty work for me.

Turned out those "DevOps engineers" were what I would call sysadmins, people who consider bash to be a readable programming language and who are even capable of managing a kubernetes cluster. But they had another rare superpower: knowing how to say NO. So ...

Devops: developers were not busy enough before so now they make them keep the infrastructure running now too. It is horse shit. Without separation of concerns its also bad security policy.

Developers who like shiny objects should simply not be on production machines. What happens when I press this button? What happens when I press this button?

Oops. Production is down.