Hacker News new | ask | show | jobs
by woah 3375 days ago
DevOps/infrastructure engineer is basically a programming position, which sysadmin/IT types may not have strong skills in.
3 comments

So what were sysadmins before the term DevOps was invented ~5y ago?

Unless you are arguing that people never did large scale automation of processes around deploying systems and software until this term existed...

In my personal vocabulary - there were always 2 kinds of sysadmins:

- Real sysadmins- which is now the term 'DevOps'

- IT System Technicians - which is what sysadmin is being perverted into

The old-style breakdown typically depended on how systems/development minded the company was - with more forward looking companies seeing their sysadmins as the former category and people who "administered" e.g. 'tended to' the IT "system", and the reactive companies who viewed IT as some foreign expense to be managed viewing their sysadmins as advanced IT techs who were 'admins' (in the administrative assistant sense) for the various 'systems' (e.g. computers) that they purchased.

As someone who always operated in the mindset of the former category, but unfortunately has operated mostly in the latter type of company, it is difficult to make the transition into 'DevOps' roles since this term has been subsequently invented to describe the work that I always did, using tools that I would have written from scratch myself in the old days, or deployed myself in the current days, but unfortunately due to crappy management and backwards modes of thinking, don't have the proper 'current' job-title on my resume (e.g. sysadmin)

Its easy to spot the difference.

If you talk to someone about their day and it revolves around tickets, they are the techs that you're talking about. The real "sysadmins"/devops understand systems and own things.

It's ok to realign your title with function. Every company handles this sort of thing differently. I was a "Computer Systems Programmer 3" for two years. In that organization, that rank was roughly equivalent to a Staff Engineer. My resume says "Lead DBA", as that was my primary function... the formal title assigned was just whatever was available when I was promoted... the title description was written for mainframe people!

No one is going to check that your title matched at most companies I've worked. Yes if you list yourself as VP of Finance and you were actually an Accounts Payable administrator, you will have some trouble. But that trouble will start far before the background check. If you're in a DevOps role that happens to be called System Administrator, simply change what you call yourself. You will still have to interview as a DevOps person of course -- titles are not reality -- but you'll get far more inbound interest, guaranteed. And according to what you've written here, you won't be lying or even misleading the people who want to talk to you.
I wouldn't call Ansible and Terraform programming languages. In two and a half years at a well known startup, I've written less than 1000 lines of code in a senior DevOps/Infra role.

DevOps/infrastructure is knowing how to glue together off the shelf tools and understanding how everything works. Great that as a dev you can probably bolt these tools together with docs, but your lack of context with the underlying fundamentals will eventually bite you.

> DevOps/infrastructure is knowing how to glue together off the shelf tools and understanding how everything works.

That's actually not that much removed from quite a few programming jobs. It's mostly different manuals and the occasional plug to fit into a socket but other than that the differences are smaller than the similarities and debugging skills are important for both of them.

Agreed.
Some of the more junior/limited roles amount to that. Higher-end roles involve a much, much broader skillet including development.
Higher end roles are architecture. If it's development, you're a developer.
Google and Amazon have plenty of SRE / System engineers and roles with "developer" in it. All of them write code.

And, thankfully, no architects.

They definitely have people who architect their systems. Just because there isn't a formal title doesn't mean they are not there.
The rest of the world is not Google and Amazon (thankfully).
This is dead but I thought I might comment anyway..

Your comments convey a very narrow perspective of the job market that falls under "DevOps". That is to say, the sphere of roles looking to be filled by companies who believe they are filling a "DevOps" role is much larger than what you believe. It almost seems as if you are limiting yourself and projecting that onto the entire job market.

Now, I'm not sure you consider your current position as "limiting".. However, I can say that there are MANY roles being filled for "DevOps" candidates that extend beyond writing Ansible roles or Chef cookbooks. Speaking as someone 6 years into their engineering career and as the person who wrote the initial powershell(as a linux cloud engineer!) feature provider for Chef, I would not have taken a role such as you describe after year 1.

Now, you may be in a position where writing Ansible or Chef resources long term sounds swell. That's fare! But there are many, MANY roles that fall into the systems engineer/SRE bucket that are labeled at DevOps! Honestly, they are a matter of degree! The higher-end roles are senior, lead, unique, and require heavy development skills. If it's not the provisioning platform you are developing and supporting, it's the performance characteristics of the product itself.

> workers need consulting help around how to take existing skills and use them to apply to upmarket jobs with higher pay.

> DevOps/infrastructure engineer is basically a programming position

sysadmin/network admin ==>> DevOps

IT manager => Manager or lead.

DevOps is not a programming position at all. It is usually cheap system administration (that replace the term sysadmin) and it does NOT require coding. Pay attention to the name and the place you joins, you're can easily be burnt by joining a team of operations monkeys while thinking they were the dev and system type persons.