4 ms·

The author didn't get DevOps (so don't many companies). It's not about putting developers on-call, it's about taking operational concerns into account early in

by jupp0r 8y ago

The author didn't get DevOps (so don't many companies). It's not about putting developers on-call, it's about taking operational concerns into account early in the design of a piece of software and acknowledging that it's going to do much better in the wild when the people building it are also accountable to making it easy to operate. Blaming DevOps (or full-stack, for that matter) for a toxic company culture is just too easy.

SideburnsOfDoom 8y ago
Yep. I disagree with the premise that DevOps is only a result of "the multiple technical roles that engineers at start-ups were forced to play due to lack of resources" and is therefore unnecessary, even harmful in larger organisations. So in larger organizations, people can and should specialise more, and not everyone should be "jack of all trades". But there is an important lesson in DevOps: owning your software from creation through testing, deployment and observing how it runs in production cases, and being partly responsible for handling Operational issues in it has great benefit. It closes a feedback loop that will greatly benefit your software. It doesn't matter if your organisation is large, that learning from the truth of production is still available to you.
joeldg 8y ago
he absolutely has no clue what DevOps is supposed to be if he is confusing full stack guys with DevOps
habeebtc 8y ago
Exactly so. I'm involved in a DevOps transformation at my company, and have been exposed to the topic over the last few years, including attending the Delivery of Things conference in 2016. What I've learned is that: 1. DevOps is simple to explain 2. For some reason, everyone has their own idea on what it means, and most of them are wrong Key points from my perspective: 1. DevOps is an evolution of Agile and so all agile practices are a subset of DevOps. This point obviates the need for any points past number 2 below. 2. It's a process which is supposed to get operational knowledge involved in the development process much earlier to build it right the first time Its over aim is to combat the fact that you can be proficient in only so many things. As you become more specialized in one area, your time becoming proficient in other areas suffers. So a pure dev is unlikely to know much about QA or Hosting, but that domain knowledge would be valuable for them to have in their daily duties. So you try and implement a process by which they have regular access to where that domain knowledge lives, and can make use of it. It's really just a way of trying to solve the "Jack of all trades, master of none" problem. Put another way, it shouldn't be shuffling more duties onto the dev to save money on headcounts, but a way of increasing the value (not volume) of a Dev's already high-value work.
- delaaxe 8y ago
  Tim Ferris has something interesting to say on "Jack of all trades, master of MANY" https://tim.blog/2007/09/14/the-top-5-reasons-to-be-a-jack-of-all-trades/ https://tim.blog/2007/09/14/the-top-5-reasons-to-be-a-jack-o...
  - barkingtoad 8y ago
    Generalists are never going to happen. In this industry people only hire Specialists.
  - rhacker 8y ago
    Absolutely agree, And: https://www.facebook.com/notes/kent-beck/paint-drip-people/1226700000696195/ https://www.facebook.com/notes/kent-beck/paint-drip-people/1... The Paint Drip concept has been around for a while now, so I'm surprised people still reference "Jack of all trades, master of None" especially in the software dev industry.
scruple 8y ago
> it's about taking operational concerns into account early in the design of a piece of software and acknowledging that it's going to do much better in the wild when the people building it are also accountable to making it easy to operate. I agree that it's important to be thinking about these future states and having those conversations from day 1. But, I also think that it's easy to abstract away all of the various pieces and dependencies of some application, because we're sold by cloud providers that this design is "reliable" and "robust" and more generally speaking "a better design." But, what if those things aren't actually needed at that point in an applications life? What problem is really being solved if these things don't present a problem? If the application has a few dozen daily users, why is every single piece of it an AWS service vs. a single AWS EC2 instance? It gets even worse than this, of course. I've seen instances where a team of developers had no idea their application was using ElastiCache and experienced application outages as a result of AWS maintenance windows. Sometimes, I guess, it just strikes me as putting the cart before the horse. And specifically with AWS (but somehow less so with Heroku or DigitalOcean, in my head).

by jupp0r 8y ago

SideburnsOfDoom 8y ago

Yep. I disagree with the premise that DevOps is only a result of "the multiple technical roles that engineers at start-ups were forced to play due to lack of resources" and is therefore unnecessary, even harmful in larger organisations. So in larger organizations, people can and should specialise more, and not everyone should be "jack of all trades". But there is an important lesson in DevOps: owning your software from creation through testing, deployment and observing how it runs in production cases, and being partly responsible for handling Operational issues in it has great benefit. It closes a feedback loop that will greatly benefit your software. It doesn't matter if your organisation is large, that learning from the truth of production is still available to you.

joeldg 8y ago

he absolutely has no clue what DevOps is supposed to be if he is confusing full stack guys with DevOps

habeebtc 8y ago

Exactly so. I'm involved in a DevOps transformation at my company, and have been exposed to the topic over the last few years, including attending the Delivery of Things conference in 2016. What I've learned is that: 1. DevOps is simple to explain 2. For some reason, everyone has their own idea on what it means, and most of them are wrong Key points from my perspective: 1. DevOps is an evolution of Agile and so all agile practices are a subset of DevOps. This point obviates the need for any points past number 2 below. 2. It's a process which is supposed to get operational knowledge involved in the development process much earlier to build it right the first time Its over aim is to combat the fact that you can be proficient in only so many things. As you become more specialized in one area, your time becoming proficient in other areas suffers. So a pure dev is unlikely to know much about QA or Hosting, but that domain knowledge would be valuable for them to have in their daily duties. So you try and implement a process by which they have regular access to where that domain knowledge lives, and can make use of it. It's really just a way of trying to solve the "Jack of all trades, master of none" problem. Put another way, it shouldn't be shuffling more duties onto the dev to save money on headcounts, but a way of increasing the value (not volume) of a Dev's already high-value work.

delaaxe 8y ago
Tim Ferris has something interesting to say on "Jack of all trades, master of MANY" https://tim.blog/2007/09/14/the-top-5-reasons-to-be-a-jack-of-all-trades/ https://tim.blog/2007/09/14/the-top-5-reasons-to-be-a-jack-o...
- barkingtoad 8y ago
  Generalists are never going to happen. In this industry people only hire Specialists.
- rhacker 8y ago
  Absolutely agree, And: https://www.facebook.com/notes/kent-beck/paint-drip-people/1226700000696195/ https://www.facebook.com/notes/kent-beck/paint-drip-people/1... The Paint Drip concept has been around for a while now, so I'm surprised people still reference "Jack of all trades, master of None" especially in the software dev industry.

scruple 8y ago

> it's about taking operational concerns into account early in the design of a piece of software and acknowledging that it's going to do much better in the wild when the people building it are also accountable to making it easy to operate. I agree that it's important to be thinking about these future states and having those conversations from day 1. But, I also think that it's easy to abstract away all of the various pieces and dependencies of some application, because we're sold by cloud providers that this design is "reliable" and "robust" and more generally speaking "a better design." But, what if those things aren't actually needed at that point in an applications life? What problem is really being solved if these things don't present a problem? If the application has a few dozen daily users, why is every single piece of it an AWS service vs. a single AWS EC2 instance? It gets even worse than this, of course. I've seen instances where a team of developers had no idea their application was using ElastiCache and experienced application outages as a result of AWS maintenance windows. Sometimes, I guess, it just strikes me as putting the cart before the horse. And specifically with AWS (but somehow less so with Heroku or DigitalOcean, in my head).