Hacker News Reader

Comment by shitloadofbooks | Hacker News Reader

"DevOps Engineer" is simply just title inflation.

In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer" - both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code. Anyone not doing that is just a _bad_ "Systems Engineer"

Developers don't call themselves "Agile Developers" because they started using agile methodologies or "CI Developers" with the boom of CI, but for some reason Ops guys want to call themselves "DevOps Engineers" because they read The Phoenix Project.

People talk about automation as if automation = DevOps, but I believe automation is a side-effect of the shared empathy which DevOps fosters. Because you have that empathy with your devs, you realize that their main goal is to be able to get their code in front of users _as fast as possible_. Automation is the answer to that.

View on HN

> In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer"

I don't find the title 'Systems Engineer' to be in widespread usage at tech startups in SV, so I'm not sure what to expect from one. To be honest, I would expect Systems Engineers to be working on hardware.

The infrastructure automation work done at modern tech startups is best described by the title 'DevOps Engineering'. If you're posting a job where the requirements include using automation code to set up and configure CI/CD, monitoring, alerting, Databases, Analytics, AWS, GCE, Heroku or other 3rd-party SAAS tools, the job title in widespread usage that encompasses that is DevOps. The Webmaster, Ops, DBA, SRE, IT, Systems Engineer, and SysAdmin titles describe different skillsets and are therefore less useful for describing a role with these kinds of requirements.

Here's an AWS-specific, but otherwise useful reference of a modern 'DevOps' skillset: https://aws.amazon.com/certification/certified-devops-engine...

"Systems Engineer" seems to be an overloaded term. In the area I work in (applied R&D, East coast) the role is a mix of the software architect and QA, but encompassing both hardware and software.

Some science background (whichever science is relevant to the project) but mostly a lot of experience in general engineering practices (what generally works, how things break, what is sufficient to test to feel good that a unit will still work when moved from point A to point B, etc.). Many have software skills, but some do not. It is generally a high level role so not all projects have one even part time, but those that do tend to have it scoped roughly the same.

Projects that deal with field work / tests, especially bringing stuff to faraway / hard to get to places tend to value systems engineers (defined as above) highly and almost always have one at least part time. Just my experience.

Again systems engineer can have more meanings still, when I hear systems engineering I think of interaction specification of mechanical / electrical systems particularly in automotive, rail, and aerospace.

managing actual physical systems, not software, although the skills are similar besides domain specific knowledge.

I've also heard "Systems Engineer" used as a synonym for "Sales Engineer". That term is too overloaded to be useful.

Whilst I 100% agree with you and wish it wasn't the case, title inflation is kinda necessary when the pay and authority reflects the BS titles.

I'm not sure what it's like over the pond, but here in London I sit round tables with a bunch of "(security, system, application, cloud) architects" with less than a couple of years experience in the industry (or sometimes 10 years of one years experience) who think they have a remit to define how things work. In a silly bureaucracy, you have to play the game or you won't have a seat at the table.

I do wish it wasn't so, but also having the title doesn't prohibit you from actually doing devops either.

It is not the engineers that call themselves 'Devops'.

It's the recruiters and managers.

Every engineer that I know that holds the 'Devops' title hates it, but has no choice in it.

I've observed this, but it depends on experience level.

Folks with <5 years experience, tend to enjoy the DevOps portion of their title. Whereas, neckbeards with a deep background tend to dislike it.

Confirmed! I am not a devops engineer. I am a systems/infrastructure engineer with a continuous integration/deployment skill set and experience.

But recruiters look for devops in my title. So, in the word goes. Hate the game, not the player.

That is because DevOps is basically what 'a good sysadmin' always did, only now it has a title, and those in the sysadmin role now 'don't have relevant experience' because 'devops' is not on their resume, and 'systems administrator' has been re-associated with 'server tech' as a result..

On the flipside, there are people who valiantly call themselves "DevOps engineers" but are nothing more than glorified remote hands.

Thanks to the recruiters and the all-too-common association that "devops = the new ops", the very term has suffered a massive devaluation. I learned this the hard way - I was foolish enough to try to hire DevOps Engineers. That's a two-month span of my life I will never get back. That's why I came up with the idea of renaming it as a search for Infrastructure Engineers.

... only to find out that I wasn't the first one. The signal/noise ratio had obviously been a problem because other companies have used the term before I did, but on the other and, even more companies have joined the crowd since then.

(It was interesting to see this blog post, because it has almost the exact title I have had in mind for my WIP longer post on the same topic.)

True, that! Recruiters, marketers, managers, PR people .. they all insist on having their own handle on 'their engineers' in some way or another..

"the shared empathy which DevOps fosters". I haven't heard it described like this before but I like it a lot. The way you phrased it emphasizes the "put yourself in other people's shoes" philosophy. An attitude that I would argue is the key to a successful DevOps process.

"DevOps Engineer" is simply a title.

And if it's the same job, to me it seems like a better title, less vague, more descriptive & accurate. Referring to "operations" seems to more clearly describe what it is that a DevOps or Systems engineer is doing, to me anyway, than the word "systems".

I'd speculate wildly that DevOps engineer is a title that web companies use, and system engineer is a title that non-web companies use for roughly the same job. But to me, for some reason, the two terms invoke images of pretty different day to day activities.

> for some reason Ops guys want to call themselves "DevOps Engineers" because they read The Phoenix Project

Are you saying that they don't deserve the title Engineer, and should be called "Ops guys" on the job application?

While I agree there is some title tweaking going on, IMO the empathy you speak of needs to go in both directions, especially if you're a smaller organization. It really needs to be, as you say, shared.

If shipping shit yesterday is the only goal your developers have in mind, they really can't expect quality Systems Engineering. They need to recognize that Systems Engineering is very much Engineering in the same sense as development and sometimes it can be just as if not more difficult and intellectually demanding especially in the face of such social pressures. Everyone needs to be on the same page.

Hence the need for such a culture and probably for an elevated title. I speak as someone who's worked in both roles and who's never read The Phoenix Project (tbqh).

> both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code

Wait have I been using the wrong definition? I thought DevOps were devs that also setup/maintain their own infrastructure

Yeah, please stop using that definition immediately. It's incredibly unhelpful, and just encourages management to understaff.

To be fair it does look like that's what it's supposed to mean. It looks like a combination of Dev and Ops, at a glance it should mean it describes a combination of roles too.

I tut at management as much as the next guy but whoever came up with DevOps didn't really help themselves there :)

Well, the full term is Development Operations, meaning the branch of Operations concerned with supporting Development. I recoiled from the definition you offered because I've actually witnessed an organization use that as a justification for not hiring any Operations staff, which is a terrible idea.

That is NoOps, but somewhat depends. You could have a developer who has a dedicated job of managing the infrastructure, but still doing some development work. Also don't forget the build engineer part for automating deploys. But if the responsibility is spread across the team, that is NoOps. It also tends to lead to a tragedy of the commons situation, because no one steps up to do the things that aren't fun.

> "automation is a side-effect of the shared empathy which DevOps fosters"

I'd upvote you twice if I could. That is a an excellent phrasing.

I've long felt there's nothing more indicative of a high-functioning devops culture than a viable continuous delivery pipeline, but making the pipelines the goal would be to miss the point entirely.

DevOps, is a developer, that do admin stuff, because the development environment became more complex with the introduction of virtualization , cloud technologies and big data

Admins who do Dev work should be called OpsDev ...

A DevOps, is a Developer , someone who started as a developer and now do extra admin and systems work

Not the other way around ..

I kind of agree with you that having this distinction would be useful. The real key is it isn't about "dev work". It is a cross between Ops, Dev, and Build. The build is actually more important than the Dev. Even bigger is who you report to. In the old world as Ops you reported to an Ops manager. The to Devops is that you report to the Dev manager, hence breaking down the silos. You could just call it Devops, but I call it embedded Devops to be clearer.

On the flip side I seen just how poorly Dev managers and Dev team leads can understand Ops. It is even worse when they think they do, but don't. This can make Devops painful.

There is also a problem with having an individual Devops on each Dev team. You will end up with each Dev team doing things completely different ways. One will be Ubuntu, one Debian, one CentOS, one instances, and one containers. There should be some standardizing force across the teams.

the key point i was trying to highlight, is that .. DevOps .. is really a Developer .. not a system engineer

a Developer that does extra stuff

there is a huge difference between a developer who does extra stuff, and a system engineer who does .. extra stuff

the barrier of entry to becoming a developer is a lot bigger than the barrier of entry to become an admin or system engineer

> the development environment became more complex with the introduction of virtualization , cloud technologies and big data

Eh. Spinning up a new VM is wayyyyy easier than racking a new box. And deploying to an app-running service is generally way easier than managing a bare-metal/load-balancer/etc-interfacing deploy script.

A devops engineer building and maintaining that infrastructure is a split that makes sense to me, but generally doesn't obviate the need for systems/network admins and engineers, as you still have problems and issues with the underlying things often come up (sometimes it's outsourced to a cloud provider, though).

honestly i am not really sure what you mean by "a split that makes sense to me", split between who?

the article of this thread/post have a very nice diagram at the top .. if the DevOps is focused more on the tasks on the right (ops) in my opinion he is not really a Devop

Builder are maintainers of the infrastructure are not DevOps .. they are just Admins

Developers of the software used to make this infrastructure possibles, are just Developers

Title inflation is generally something one does to one's own title though isn't it? Isn't it also done to "inflate" the perception of one's status to others. I don't believe that's whats going on with "DevOps Engineer" at all however. If anything its just an unfortunate misnomer.

DevOps Engineer is not being promulgated by the engineers themselves but by both recruiters and managers.

A quick search using "DevOps Engineer" on a job site like indded.com returns 196 matches. There is even "Senior DevOps Engineer" jobs listed.

The other contributor to the circulation of this as a title is companies that have a DevOps department and then by extension engineer in that Department become known to management as DevOps Engineers.

Reply on news.ycombinator.com