This was a totally misguided re-branding of the field. It attracted bureaucratic personalities and classist managerial types, and utterly destroyed the field.
Like you, I couch my job description: I'm a "Systems Software Developer, I develop software systems" .. because its true, thats what I do, even if its a majority of the time working on embedded projects.
And if someone then responds with "ooh, so you're in IT", I immediately go to another corner of the party and avoid them like the intolerable bores they are ..
No need to be arrogant towards people outside the field. My grandma doesn't know the difference between the random IT guy that updates your Windows printer driver and a Linux kernel dev, but I'd still not call her an "intolerable bore".
Hard to convince management that a dedicated onsite IT would be required - especially when they think it is your job already.
Gotta appreciate if you're working in the former. Drawback is you can't BS your way through issues. Everybody above me in the chain (which is like 4 people) could write a quicksort blindly. If anybody tries any BS they don't have their job much longer.
Well, nobody forces you to work for a company with managers like that. I personally wouldn't.
That's kind of like saying, even slaves have a choice. Death being the option available to all.
Drawing a comparison to slavery is quite shocking, tbh.
It isn’t a problem for my ego to do that, and it’s something that’s both relatable and typically stops the conversation from revealing anymore about my work (not that there’s really anything to hide, I just enjoy my privacy and no, I don’t want to meet your “computer genius” nephew or fix your phone).
If I’m in a clearly technical group, I’ll go into more detail. I don’t identify myself with the DevOps term though, or sysadmin, or developer. I don’t clearly fit into any of the -currently assumed- definitions of those.
In social situations, I usually just say "I'm into computers". Most people who ask what I do don't really care, they're just engaging in ritualistic small talk anyway. If someone does care, they'll ask clarifying questions.
I always default to "I work in IT". If that person is in the space I might go into specifics; but even then majority can't relate or understand the role i spend my days working in.
It also has the benefit of coming across as more blue collar and I catch less grief, as the disdaine for tech workers continues to grow.
A good example is how software releases work. Where I worked 15 years ago, releases were something we could afford to do about four times a year, at night, on the weekends, doing the rollout by logging onto machines and starting them back up, babysitting the rollout. Because rollbacks were catastrophic, an insane amount of time went into QA, so the time between a code change and a release could be easily multiple months. Now I'm at a place where releases are done every day of the week. Rollout steps are largely automated. Rollbacks are mostly drama free. Risk is mitigated through automated canarying (and automated testing before that).
And certainly the business has successfully gotten rid of paying people to log in to servers on a Saturday night to perform a release (which frankly not a lot of people are into in the first place, so everyone wins).
https://www.linkedin.com/jobs/junior-devops-engineer-jobs/?c...
No programming experience required (only some minor scripting in shell languages & a reference to education), in fact this job ad reads identically to a sysadmin job from 2014; in the middle of the "sysadmins can't code" zeitgeist, when all developing sysadmins had moved to become devops engineers or whatever.
Copied from the ad:
----8<---- Your tasks:
* Containerization and orchestration of our products for development, testing and production environments designed for cloud and on-premise solutions
* Produce reference architectures and standardize solutions to streamline efficiencies within the business
* Mitigate against Cybersecurity threats by ensuring systems are safe, secure and compliant to best practice recommendations (e.g. CIS Benchmarks, Vulnerability scans and Penetration tests)
Your profile:
* Finished studies in Computer Science or software engineering (Bachelor, Master)
* Proficient understanding of virtualization, containerization and orchestration (e.g. Kubernetes, Podman)
* Experience working with CI/CD tools such as Azure DevOps, Jenkins
* Experience of Infrastructure as Code tools such as Ansible, Terraform, Helm
* Scripting knowledge including bash, PowerShell
* English fluently, German is an advantage;
* Improvement-driven, structured and proactive team player, high sense for quality, open minded
* Working in an agile environment (Scrum, Safe)
---->8----
Proficient understanding of virtualization, containerization and orchestration (e.g. Kubernetes, Podman) Experience working with CI/CD tools such as Azure DevOps, Jenkins
The point is coding skills are not required to do the job. Sure it would be nice but if somebody ticks all the other boxes then being good at programming isn't important.
What I'm trying to drive home here is that you do need programming experience to be a good sysadmin/devops/platform; back when devops as a job title was becoming "a thing"(tm) I was told over and over again that sysadmins couldn't code and thus we need devops.
Now it seems devops don't need to be able to code (which you seem to think as well). So we will come up with a new term to cover programmers who understand systems.
Those "degree" sections are universally optional, they're always listed by I have never seen them honoured.
I'd put $20,000 down on the wager that I could get that job with only a Cisco certification (or even nothing at all).
But the criticism was that the job ad was not requiring knowledge of how to write code, and I was pointing out that the degree requirement (strict or not) indicates that that's not true.
If you don't have the required degree but can demonstrate equivalent skills, then that's fine. Kudos to the company about being flexible on the formalities side.
There is a line that is universally ignored in job ads. This is that line.
if I showed no ability to write a for loop or a linkedlist. I could still get that job.
I see it time and time again, it's like we must add that line to job descriptions, but it's never checked, never verified and ultimately it serves no purpose. There will be no difference between someone with a BSc in CompSci, an MSc in CompSci or no degree at all.
The thing that will get you that job, likely, is discussing how http works, how tcp works and perhaps something to do with exit codes.
Might not be true for this particular posting.
The only european country that takes titles even more serious is Austria. So without a M.Sc. in CS or a similar M.Sc. your chances may be quite low to even get an interview. Especially since university is basically free here so many people have a B.Sc. or M.Sc. in germany.
No BSc or MSc here.
I’m sure this is the case in some places. This can’t be farther from the truth in many others. At every organization I’ve been a part of, the best “DevOps” on the team was usually the person who was the best at coding, or at least understood it the best - and coding is one of those things that you can’t really understand well if you don’t do a lot of it.
But plenty of developers only have a vague picture of what production looks like especially in a complex environment. However they are perfectly able to do their job okay and produce working code.
Sure, maybe some of the work isn't writing software. But some of it is, and it shouldn't be written by amateurs. Also, they are building these things for people who do write software. It would be hard to produce something that works for them without understanding what they do.
Reading code, understanding building and deployment are all useful and required to some extent (especially the latter). But specific programming skills are not required any more than that would be for say a technical writer or network engineer.
That typically entails programming experience, especially in Germany.
Most companies do. Perhaps not top Silicon Valley tech companies with cutting edge needs and paying over $150k, but overall I've found that dev ops teams have plenty of jobs for 'green' team members. You just have to accept a 'green' salary and 'green' job responsibilities.
Yes. Devops people come from a SWE background generally + they understand infra. They usually have 10+ years experience. Most specialties work this way in software: security, devops, AI, ML, ... etc. You need to be a SWE first, then specialize.
Also I work in AI/ML and hardly anybody has 10+ years of SWE experience before specialising. Most people start fresh out of a PhD or postdoc program or come from some sort of math or physics background.
Now it's actually 80:20 due to software engineers becoming frustrated and disillusioned with the current state of things. Not only due to specialization and the push towards tool standardization (you don't get to build many custom components because we k8s all the things so most of the time you're just writing yaml/hcl), but because working with regular sysadmins gets extremely frustrating.
This could be the entire problem. These are specialized fields. They are being treated like they are not.
[Weeps] That wasn’t the point, the point was exactly the opposite of that, to get developers and ops working as a single team, building an understanding of each other’s domain in order to make things better. Sadly the point was lost long ago, and devops engineers and devops teams have taken the place sysadmins and ops teams in providing a nice little silo you can chuck your terrible code over the wall at and not have to think about how it works.
But you know what? There are tons of developers who are _perfectly fine with this_! There are tons of developers who just want to write business code in their CRUD webapp and call it a day, the more abstractions you can give them, the happier they are. And while I don't like it, I don't blame them.
the ole “runs on local therefore it’s good to go” should be good enough.
Which database you choose and how you scale it will affect your application code.
You can't write code that makes use of the local file system (or in-memory data for anything meant to be persistent) if you have more than one container serving your app. (And yes, some people need to be explicitly taught not to do that.)
And so on.
Where this falls down is when development teams are building complex systems and then expecting the ops team to divine how that’s meant to work in production.
A lack of gatekeeping I don't think was ever the issue; the incentives were just perverse.
I spent time working around the space industry. Almost a decade of my life.
The big contractors in aerospace have a _really_ difficult time finding people who know enough about the hardware and the software to be competent engineers. They’re basically unicorns.
Not that they don’t exist, but if you’re looking for someone who is demonstrably good and has a validated educational background in both, you don’t have a huge pool of talent to go with.
So they hire them when they find them, but they also just tend to hire experts in each field and let them collaborate. They didn’t try to reinvent the wheel with some new “paradigm shift”.
What tends to happen is that at some point in time, an organization finds itself in a bad place. Where pagers fire regularly, and the skills you need to manage the noise are "fast context switching", "good communication", "debugging", "ability to work insane hours". Very little of this involves coding, or building software. Teams may start by assigning some engineers into this role as an elite team, but if you come back in a couple years you'll find that the elite team has burned out or forgotten how to write software and due to the impossibility of hiring new elite team members - has resorted to hiring people to carry a pager.
There are a few companies which invest in big platform orgs, but due to the lack of revenue generation - it seems that this can only be sustained with very strong leadership buy-in.
I absolutely agree with this. It seems like a it inevitable for anything that a business needs to do but doesn’t really want to do. Another place where you see it is with project management, where there have been many different titles for the same role.[0]
Definitely. often it's more about organizational changes than software and upper management is the one blessing things in most big corp.
One of the fundamental shifts in my opinion was building APIs on top of sysadmin tasks. Provisioning a VM, installing an OS, getting software onto the server, configuring ingress/egress, handling process restarts, etc.
These all were turned into tasks you could run from a developer’s laptop.
But it was still a different skillset and devops dumped that skillset on developers (“Hey! Now, instead of opening a ticket, just write a 1000 line magical incantation of poorly understood YAML and the system can do it for you!”).
Platform Engineering grew out of that pain. It’s the layer we are building on top of devops in a way. We are taking those APIs and treating them as foundations to build products that manage the SDLC lifecycle for developers.
I think at its core, deveops was about “how much sysadmin work can we turn into an API and give to developers?” The answer turned out to be almost all of it. Then Platform Engineering is “now that we have APIs, how much can we automate away for developers.” We don’t know the answer yet, but suspect we will find the answer is also “almost all of it.”
Site Reliability Engineering seems to be following a similar story arc and converging on Platform Engineering.
At my current company theres literally no coherence. Some people deploy on EKS, or ECS, or Anthos, or regular linux hosts. We use every database on earth. Things on Azure GCS and AWS. Databricks and Snowflake. The list goes on!
The team I was on was made up of ops/engineering[1] people who knew how to code. We built tools to fill gaps or let us do things we couldn't do otherwise, but would typically use out-of-the-box functionality in third-party products by default because it was cheaper in the long term than building and supporting custom code. Maybe there's a better term for this, but I think of it as "OpsDev", and AFAIK it's more or less extinct.
DevOps has always struck me as being developers[2] getting fed up with having to deal with a separate ops team, and building tools and platforms to automate away that ops team entirely.
The two things can look superficially similar, because they achieve similar goals (automate away repetitive work, let people do more work), but the approaches are almost totally different. Kubernetes and Terraform do amazing things, but they are very obviously tools written by and for developers. I think it would be difficult and unwise to hand off first-tier support for issues involving them to a help desk, for example. It's pretty safe to write instructions for first-tier support to use a GUI or run a command but substitute the name of a server farm and a software package in the arguments, especially if the command is a script written by the engineering team to verify that the work makes sense before executing it. It's a lot less safe to try to have non-developers hand-edit source code, a script or even a YAML file and push the result to production.
Both approaches work. They just require different kinds of people, and each has their own benefits and drawbacks, and IMO it's a mistake to put them both under one label.
[1] "Engineers as in Geordi LaForge or Montgomery Scott": the people whose primary job is to keep the engine(s) running, respond to emergencies, make improvements where possible, and generally be a smart-person-of-all-trades.
[2] "Engineers as in Burt Rutan": the people whose primary job is to design and build new products (for lack of a better word) from the ground up.
Somewhere along the way "sysadmin" became a euphemism for helpdesk, and some folks thought "devops" (as a job title) was new, but it was just the same old sysadmins really, or new devs becoming new sysadmins with the fresher title, they felt themselves the vanguard of a new paradigm, I'm sure.
Now we're in the same situation again, where "devops" (as a job title) can have no development experience. So we need a new term, apparently.
Maybe gatekeeping is useful to stop this job title treadmill.