Hacker News new | comments | show | ask | jobs | submit login

Was (Unix) ops ever not coding? I honestly don't know, I haven't been around that long. But all the old guys I know were "perl is unix duct tape" ops guys.

The older, more foundational problems were getting automated back then. Now that they're solved problems, and combined with more and more people running large and/or virtual infrastructure, a new problem domain exists around spinning up machines and deployment.

The current coding investment is infrastructure because it's the current pain point. In a decade (or whenever permanent solutions exists for infrastructure) the current way will be considered "by hand" and operations coding efforts will just move onto whatever problem is only visible now that infrastructure is no longer a time sink.

You can say that some ops is just admins running already existing software and operating everything by hand, but there will be admins doing exactly that in a decade too.

Yes, the devops movement is silly. In the 90s when I started, every SA knew, and used, Perl and C in their daily jobs.

Then dotcom happened and every kid with a Linux box in their bedroom put themselves about as a SA. And in the 10s people think SAs who code is an amazing new invention.

And back in the 60s, IBM had "systems programmers"... Same thing.

You're leaving out the other 80% of the industry – yes, IBM shops had systems programmers but every single one of them also had operators who were following a big run-book of canned procedures and diagnostic trees which sometimes ended with “Call <sysprog>”. Most Unix shops I've seen had a few decent developers and a bunch of people who used tools written by the first group.

The big difference I see in devops is that people started taking system management seriously enough to do first-class development rather than an afterthought.

It wasn't really that clear-cut. I started in Ops in the '90s, too, in SV, and there were plenty of SAs I knew who were proud of the fact that they weren't coders. Yes, they knew the shell, and maybe they knew a tiny bit of Perl. But as a guy who was an SA and a coder (Perl, C) I was a rarity.

I still am, but the "DevOps Movement" is here to point out that this artificial dichotomy is considered harmful.

Back in the early to mid 90s most Unix sysadmins I knew started out as computer science students, so they could code (the most practical language being C) but ended up coding less over time.

Yeah, I was never aware of a sysadmin who couldn't code.

Generally, a sysadmin has slightly different skills from a developer - they might code in a highly imperative style and always keeping the actual machine/system being targeted in mind, but I've never known a half-decent sysadmin who cannot write code.

The last time I looked for a senior sysadmin -- less than a year ago -- I didn't get anyone who was comfortable programming in Perl/Python/Ruby until I started using the term DevOps.

If that's the term the market wants to use, fine. As far as I'm concerned, a senior sysadmin who can't write in a couple of scripting languages isn't senior.

I consider myself a developer (though I call myself software engineer, due to the incompetence of other "developers" I work with).

I know a reasonable amount of sysadmin (all my computers run Linux primarily, I only keep Windows on for checking hardware issues, and a couple of specific apps I need to run once or twice a year).

I wouldn't apply for sysadmin jobs, because I wouldn't feel my knowledge is enough. I have however seen devops jobs that seem to match my skillset - developer with a bit more. I hadn't really heard of the term until I saw the job ad.

There's a difference between "Can cobble together some python" and "knows how to use a python package from pypi"

Agreed. In my experience a senior sysadmin can work as a above-passable developer. But a senior developer can rarely function as a sysadmin.

As to DBA; I can't help but feeling that the OP hasn't worked with "real" DBA's. That's a whole different ballpark and I've yet to meet a sysadmin or developer who can make even a passable DBA.

I've always thought the hierarchy goes: DBA -> Ops -> Developers. With the last two really about equals.

Thing is a good DBA is probably better than a crap developer. And a good developer is probably better than a crap DBA. Likewise with Sysadmins.

When I think about expected earnings, I would say your hierarchy is correct.

...you've never met a sysadmin that took an algebra class in college?

It's about more than just "unix duct tape". It's about 'Infrastructure as Code', treating servers like programming objects. It's about using configuration management tools like Chef and Puppet instead of writing bash scripts which only work on one system.

"DevOps" here, by which I mean an IT Ops Manager/Linux Admin/Network Admin doing this for more than a decade.

Nothing you described is outside of the realm of what your typical linux admin does. I don't have to be a senior python dev to do my job, and I've managed 5500+ virtual machines by myself (puppet/chef, bash, some python, persistent data/object storage).

Agree with the author; just shoving more hats onto less people.

It's a nice, and really needed reaction to the Microsoft view that ops people only need be able to set options on a GUI. Obviously that that never was the case, on Unix or Windows, but their marketing tried to make it look like so, and lots of people hiring and looking for a job believed it.

A DevOps can expect a bigger salary, while a company hiring one can expect way more productive candidates than if they asked for only ops.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact