Live data from Hacker News

How 'DevOps' Is Killing The Developer

jeffknupp.com

121–130 of 219 posts

Re: How 'DevOps' Is Killing The Developer

#121

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…

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.

Re: How 'DevOps' Is Killing The Developer

#122

Interesting. I always thought of "Full-stack" developers from a web perspective being capable of coding from the client to the server. Never thought of them being devs that do ops also.

I think the definition of full-stack in this article is fundamentally wrong. I say that as a full-stack engineer. heh.

Re: How 'DevOps' Is Killing The Developer

#123

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.

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?

Re: How 'DevOps' Is Killing The Developer

#124
I'm not so sure your usage of the term "full-stack engineer" is accurate here. I consider myself full-stack, but I don't know half the stuff about Chef that our DevOps guy does and I'm ok with that. To me, a full-stack engineer means that I'm capable of coding both things that make magic happen in the browser and things that make magic happen on the server side of the application. It doesn't mean I'm a jack of all trades.

That said, I don't think that the increased prevalence of DevOps is bad. And I don't think it means "everyone is doing everything" either. It's a new role that is borrowing elements from both development and operations. Not one person doing both roles.

Re: How 'DevOps' Is Killing The Developer

#125
I'm a terrible system administrator. Everything I've learned about it has come from necessity because startups. I don't want to be a system administrator and have no desire to be good at it. So I learn the minimum I need in order to get it to do what I need to do and hope that I've done it right.

I might only be slightly better than someone who's new to system administration only because I've written system-level code and understand operating systems and things of that nature.

However a good system administrator understands the entire architecture from a holistic point of view. They know the compiler switches to use, the run-time switches to tweak, the security implications of various configurations and all of the other details it takes to keep a cluster secure.

I often work well with a good system administrator to debug and optimize workloads due to the overlap in our skills. I find this to be the optimal relationship.

Learning and practicing system administration takes away from my ability to learn and be a better programmer (and the opposite is true as well). I don't know about most people but I find I can't be good at both. And I know which one I'd rather be better at (programming).

I don't think the author has hit the nail on the head but I agree that effective teams can't expect one person to manage an entire application from code to managing a secure deployment.

Re: How 'DevOps' Is Killing The Developer

#126

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.

well, in many places DevOps is implemented as "developers on PagerDuty". When I (the developer) have to be on-call for 7 day rotations, phone by bedside, paged at all hours, then I'm most definitely acting as operations - probably NOT what I signed up for. And, contrary to the stated intentions, I've directly observed developers making crappy, band-aid fixes to ongoing production problems in the interest of "making t…

Giving everyone pager duty can lead to higher quality solutions. The band-aid fixes crop up when ownership of a whole system eventually spreads too thinly.

Within the right framework, keeping everyone on pager rotation can lead to much smoother operations, because everyone stays familiar with the system as a whole. This was going around recently, and captures the essence of the philosophy: http://catenary.wordpress.com/2011/04/19/naurs-programming-a...

Re: How 'DevOps' Is Killing The Developer

#127

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.

Sounds like DevOps is new and like Agile isn't always implemented as intended once it gets into the wild at companies. I've experience Agile and Enterprise Agile at companies where meetings are called scrums but are 50 minutes long. Sound like there is DevOps and Enterprise DevOps, or some other bastardization occurring out in the wild. Oh process, oh process, save me from these hardships.

Re: How 'DevOps' Is Killing The Developer

#128

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.

Right - and I guess the point is that the person who is working on features ends up also being that one person who does the automatic provisioning and testing pipeline administration work, as well.

This is honestly why I've gone with PaaS - mostly Heroku - for several months now when deploying a new application. Why on Earth developers do anything other than working on the core features of their program I don't know. All of the things you need to set up - tesing pipeline, and containerized, automatic deployment, load balancing, databases - are now available as cloud services. There is absolutely no need for the developer to be doing administration and provisioning tasks at this point.

If you think you need to set up your own server infrastructure ask yourself one question: is there any specific technical requirement that my application has that can't be fulfilled by existing cloud services? If there isn't, and there probably won't be, you shouldn't be doing ops yourself, especially not in a startup setting where time is absolutely at a premium and you need to be spending all of it on making the best product you can make.

And before everyone tells me that PaaS is more expensive - it's only more expensive if your time is worth nothing. But your time isn't worth nothing - it's probably worth over $100/hr if you are a developer working in the United States. So Heroku ends up not being more expensive at all - especially not before you have to scale.

Re: How 'DevOps' Is Killing The Developer

#129
post #59
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…

Thanks for voicing this so well, this has been my experience as well and it's probably safe to say our systems will continue to evolve to be more complex as our tools which enable us to deal with the complexities co-evolve. Having a full picture of things will stay a requirement.

But there is a difference between "having a full picture of things" and actually painting the picture yourself. Here I mean that to have a general overview of the different parts of the system is beneficial for everyone involved. However when you need to set up and interact with all components of the system on a daily basis it becomes a very time consuming task.

Re: How 'DevOps' Is Killing The Developer

#130

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?

Whether it's detected at compile time or runtime, a statement that evaluates to DIVBYZERO can be handled. Taking the result as an ordinary value that blows up your program, on the other hand...
Post reply on HN