Live data from Hacker News

How 'DevOps' Is Killing The Developer

jeffknupp.com

181–190 of 219 posts

Re: How 'DevOps' Is Killing The Developer

#181
post #31

Earlier quoted context omitted.

from what I've seen, the term 'devops' is generally used to pay a developer less than you would otherwise while getting more from them. I'm not sure how the math of that works out, but based on what I've seen, that's what happens.

My average "devops" engineer is paid the same as the senior-level engineers within my company.

Ditto. DevOps is charged out at the same comparative rate Sys Admin was 10 years a ago. Which makes sense - it's boring work and not as many people want to do it.

Re: How 'DevOps' Is Killing The Developer

#182
It's not so much that DevOps is killing the developer as it's the expectation that you can have your regular general purpose developers do your DevOps on the side.

I can relate to the downsides pretty well - I'm the only developer in my group and my job is mostly to develop web apps, but the IT side doesn't have much knowledge of modern tools - they live in the era 'just use Drupal and Apache' so I'm often the one who ends up having to figure out the deployment of the applications I work on (and also help with random problems from their OTB apps) and such.

To be honest, I don't mind when it's DB stuff because I'm pretty comfortable with it and have plenty of background with various SQL DBs, and it's not a time black hole, but when it comes to configuring servers and deployment I hate having to deal with the DevOps because there are so many pieces I never have the time to really become comfortable with them all and I feel very inefficient. Accomplishing something doesn't always take long itself, but it can require spending a day of reading wikis and documentation to accomplish something simple when you've got a lot of moving parts. And the worst part is that you have to deal with the DevOps bits so infrequently it's like you have to relearn them each time.

Re: How 'DevOps' Is Killing The Developer

#183

Earlier quoted context omitted.

First, there exist software environments where errors cost significantly more than a hardware run. Obviously, those environments contain hardware as well, but "cost of a runtime error" is clearly not the only important thing here. Second, my only point was that the example given was a piss poor example of the difference between hardware and software. Obviously a bad example doesn't disprove the claim it's supposed to…

Everyone's piling on you because that wasn't the point of the example. Automation grants humans extraordinary powers, as long as humans aren't simply steps within the automatic system. There's been an awkward growing phase of the technology industry that has led to technicians that don't have any real understanding of the systems they maintain. Compare and contrast Robert DeNiro's character in Brazil with the repairm…

... what?

Re: How 'DevOps' Is Killing The Developer

#184

DevOps isn't amount making Developers be Ops guys. It's about the fact that automation eats everything, and a significant part of 'ops' is now coding. A DevOps person isn't someone who develops, and who does Ops. It's someone who does only Ops, but through Development. It's not about start ups vs Enterprise, it's about 1 person writing programs or 5 people doing things by hand.

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. Th…

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.

Re: How 'DevOps' Is Killing The Developer

#185
post #97
post #27

This article is pretty ignorant. I don't think most developers have the capability to be sysadmins or QA. Vice versa, too, quite often. Joe developer ain't that special. Devops is about taking moving the infrastructure into its own configuration-managed artifact, taking lessons from programming and computer science, and coming out with its own engineering rigor. If you want your devs to operate builds/infrastructure/…

>I don't think most developers have the capability to be sysadmins or QA. No, but they tend to think they can.

And/or they're pushed to do so.

Re: How 'DevOps' Is Killing The Developer

#186
post #34

You can't really draw a hard line between administration and development, in the end you are just building a system and the more you know about it from all angles the better design decisions you can make and the easier it is to fix issues. I diagnosed a few problems over the years that arose as apparent issues with a web application but that I gradually narrowed down to things like network issues, or kernel bugs, or…

I don't know - I need to know the kernel, the shell, the hardware, networking, programming, all of the services that are in prod and automation tools and how to manage a code base. Now I need to learn how to write production quality code in Node? I'm all for a tighter integration between Ops and Devs, and infrastructure-as-code can help bridge that gap, but I don't know that doing each others jobs is the solution.

Well, if the servers you are administrating run Node, you you do. Maybe not production quality, but you should at minimum know enough to read it and create a simple project.

At the plus side, you have quite a big deal of control over most of those variables.

Re: How 'DevOps' Is Killing The Developer

#187

This article pretty much resonates with my experience, except that my employer (a 4 person established company) can't afford to hire a QA and sysadmin alongside my role as developer. The bad side is that doing this DevOps role across multiple projects at the same time can lead to burnout, and I think I came close to that in the last few months. The good side is that I've learnt a great deal about how to architect and…

Nothing wrong with burnout. You'll go get yourself a better job once you wake up from it. Established mom/pop shops are the best way to break into an industry but a terrible dead end for your career.

Re: How 'DevOps' Is Killing The Developer

#189
Before you start to complain, I am a fan of collaboration but Devops might just be the best joke ever! The truth is it means something different to every person. For years I have defined Devops as Engineers trying get Ops out of the way and pushing forward with out those pesky sys admins. Your think I am over blowing it? I have been in the Silicon Valley for the boom of Devops and I hear it all the time “We dont need ops, we can just have a developer do it”. The number of new startups who use AWS thus allowing them to forgo a system administrator never ceases to amaze me. My biggest problem with this is your cutting the legs out from yourself, but your assuring me job security so maybe I should keep my mouth shut. I have been a a operations engineer for over ten years now, and honestly developers and ops engineers have different ways of functioning. To me a good software engineer has long term focus, can get deep into a project and crunch on the same code for extended durations. Give a good coder a project that will take weeks or even months and they will put there head down and solve your problem. As a generalization these people do not handle interrupt driven work well, they also often do not handle high pressure situations well. Operations people on the other hand do the majority of their work under massive interruption and constant pressure. Tell a operations engineer the site is down and they will not focus on what the origin of the problem is, they will focus on getting the product back online and come back to fully understand why. This does not mean they do not troubleshoot but they are trying to identify the immediate cause not the who or root. One might argue this is short sited but when your stuck waiting for someone to figure out why the web severs where started your killing your customer experience. I would argue restart the web pool get the product back online and then start to look at root cause once you have identified the customer impact problem and completed the shortest path solution. When you start off by having your engineers run operations you never allow new ops people to start from ground up and develop their skills, learning the pain points as the system grows thus ensuring when you grow to the point that you need a operations engineer the is a shortage of trained people available. One might argue that some of the developers that started the company by running operations will become your operations engineers and will cover this but to me thats like using a vice grips to remove a bolt.

Re: How 'DevOps' Is Killing The Developer

#190

Earlier quoted context omitted.

At least in my world view this is a much better definition of DevOps. Folks who make the world run, and through automation can keep a larger portion of the world spinning. It requires someone who can analyze failures, figure out how to predict and mitigate them, and then code automation to do so. Oddly this is much more like the 'developers' of old. If you sat down at a workstation you needed to know how to be your o…

"Imagine a computer language where 1/0 was a legitimate statement, not caught by the compiler, but always blew up in your executable." ... isn't that all languages?

Of course it is, and there are collections of letters that are pronounceable words, but it doesn't give them meaning. The equivalent in English would be a spell checker that didn't flag "douberness" and passed it along. Sure you can pronounce if if you look at it phonetically but it doesn't mean anything. It is syntactically correct but broken. VHDL has a lot of things that can be written but not actually expressed in hardware.
Post reply on HN