6 ms·

I wholeheartedly agree on most parts, with DevOps being the exception. Devs only focusing on developing/writing source code is certainly not the way to produce

I wholeheartedly agree on most parts, with DevOps being the exception. Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...

kkjjkgjjgg 5y ago
It was a bit cheeky and off-hand. I am certainly interested in DevOps. If things can be automated, it is usually a good thing. Still I think having extra admins for server maintenance, or nowadays DevOps, also makes sense in my opinion. In theory I should be interested, but in practice, somehow I can not really get passionate about the details of how to host things. So it would be better to have specialists who really care. Ultimately there are also a lot of aspects that are different from the programming problems. It's difficult to keep up to date on both fronts.
- verinus 5y ago
  Ok no argument from me there :) Maintenance and the automation of repetitive tasks are in my view part of DevOps, but not every dev in a team has to participate at the same degree...
baash05 5y ago
I am 100% not interested in ops. Deploying is handled by other way more qualified than I. I never expect a JS expert to build elixir, I don't expect an elixir expert to write bash, and I don't expect a bash expert to know about switches and cabling. I don't understand where you draw the line.. Should the designer who also crafts the css do ops too? I think high quality comes from specialists. Sharp knives in the hands of pro's
- 3np 5y ago
  Just like the preceding question, it depends on context. In a huge organisation, it can work well to be very specialized. In, for example, a smaller growing business with an engineering team of < 10, having a proper understanding of the context in which your code will run is a game-changer.
- verinus 5y ago
  The goal is to sustainably build software, which only can be done if ops and maintenance is regarded a goal, a pillar to build upon. Like TDD the design of software changes when you have experience with ops/maintenance. Take logging/tracing: what to log or trace is first and foremost a matter of experience with maintenance/ops! Building in logging/tracing/monitoring from the get-go because you know that you want to know what goes wrong, when it goes wrong etc... can one regard oneself as expert if you know only a part of the domain- I think not!
  - deleted 5y ago
    [deleted]
- deleted 5y ago
  [deleted]
- nerdponx 5y ago
  And this person is a DevOps person, in every org I've ever worked in. Maybe "before my time" it was a webmaster or other admin. I think of "dev ops" as an umbrella term subsuming many specific titles and roles from the past, much like "data science".
- mrweasel 5y ago
  > I am 100% not interested in ops I suspect you don't mean it like that, but developers have to care just a little about operations. There's the classic stuff about developers who build stuff, because they didn't realize that ops could do the same with a few lines in a web server config, so they waste weeks on trivial stuff. There's also the issue that if you expect databases, queues, disks and so on to just be available, while not thinking about how you use them, then you can get bad performance or cause downtime and crashes in the worst case. The initial idea of DevOps also seems to have been twisted to having developers do operations, rather than having the two teams work in tandem. If we absolutely must combine the two roles, I'd be more comfortable having operations do development work, but that hardly ideal either.
  - geekbird 5y ago
    These days DevOps is used as a bludgeon to fire sysadmins and make devs pretend to manage infrastructure. The idea from the corporate viewpoint is to save money by not having anyone to handle systems stuff, just shove into "The CloudTM" as serverless microservices, then just restart it when it falls over instead of troubleshooting. Yes, I'm cynical. Having to use javalike stuff to do what should be a simple shell script will do that to you.
varjag 5y ago
If we were interested in ops we would be sysadmins.
svckr 5y ago
I don't know. I totally agree on the premise that developers should be involved in ops as well. But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space. (Insert joke about the CNCF technology landscape map.) There's just so many tech/tools/etc. involved that just reasonably "doing the ops stuff" on the side seems way unrealistic. Sometimes I feel that all we've accomplished was job security for legions of consultants.
- DerArzt 5y ago
  I am sort of with you on the whole: > But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space. At the same time, I am conflicted. I don't care for the toss-it-over-the-wall approach that used to be the norm, but I also don't like having dev's have to take more on than they are capable. In an ideal environment, I would like to see a crashing together of developers and operations people on teams. What I mean is that for a given team you have several developers and one or two ops folks. This way there is less of an us vs them sentiment and teams can be held accountable for their solutions from ideation to running in production. Finally while it's not the sole responsibility of the dev's to manage their DevOps stuff, they will have more knowledge of how it works, and get to put input and ideas to it.
  - geekbird 5y ago
    This was the original intent of DevOps - a cultural shift that put sysadmins/ops people into the dev team, thus have a better feedback loop between dev and prod, and tear down the wall between dev and ops. But now it's being used as a way to eliminate ops people and push it all into dev.

kkjjkgjjgg 5y ago

It was a bit cheeky and off-hand. I am certainly interested in DevOps. If things can be automated, it is usually a good thing. Still I think having extra admins for server maintenance, or nowadays DevOps, also makes sense in my opinion. In theory I should be interested, but in practice, somehow I can not really get passionate about the details of how to host things. So it would be better to have specialists who really care. Ultimately there are also a lot of aspects that are different from the programming problems. It's difficult to keep up to date on both fronts.

verinus 5y ago
Ok no argument from me there :) Maintenance and the automation of repetitive tasks are in my view part of DevOps, but not every dev in a team has to participate at the same degree...

baash05 5y ago

I am 100% not interested in ops. Deploying is handled by other way more qualified than I. I never expect a JS expert to build elixir, I don't expect an elixir expert to write bash, and I don't expect a bash expert to know about switches and cabling. I don't understand where you draw the line.. Should the designer who also crafts the css do ops too? I think high quality comes from specialists. Sharp knives in the hands of pro's

3np 5y ago
Just like the preceding question, it depends on context. In a huge organisation, it can work well to be very specialized. In, for example, a smaller growing business with an engineering team of < 10, having a proper understanding of the context in which your code will run is a game-changer.
verinus 5y ago
The goal is to sustainably build software, which only can be done if ops and maintenance is regarded a goal, a pillar to build upon. Like TDD the design of software changes when you have experience with ops/maintenance. Take logging/tracing: what to log or trace is first and foremost a matter of experience with maintenance/ops! Building in logging/tracing/monitoring from the get-go because you know that you want to know what goes wrong, when it goes wrong etc... can one regard oneself as expert if you know only a part of the domain- I think not!
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
nerdponx 5y ago
And this person is a DevOps person, in every org I've ever worked in. Maybe "before my time" it was a webmaster or other admin. I think of "dev ops" as an umbrella term subsuming many specific titles and roles from the past, much like "data science".
mrweasel 5y ago
> I am 100% not interested in ops I suspect you don't mean it like that, but developers have to care just a little about operations. There's the classic stuff about developers who build stuff, because they didn't realize that ops could do the same with a few lines in a web server config, so they waste weeks on trivial stuff. There's also the issue that if you expect databases, queues, disks and so on to just be available, while not thinking about how you use them, then you can get bad performance or cause downtime and crashes in the worst case. The initial idea of DevOps also seems to have been twisted to having developers do operations, rather than having the two teams work in tandem. If we absolutely must combine the two roles, I'd be more comfortable having operations do development work, but that hardly ideal either.
- geekbird 5y ago
  These days DevOps is used as a bludgeon to fire sysadmins and make devs pretend to manage infrastructure. The idea from the corporate viewpoint is to save money by not having anyone to handle systems stuff, just shove into "The CloudTM" as serverless microservices, then just restart it when it falls over instead of troubleshooting. Yes, I'm cynical. Having to use javalike stuff to do what should be a simple shell script will do that to you.

varjag 5y ago

If we were interested in ops we would be sysadmins.

svckr 5y ago

I don't know. I totally agree on the premise that developers should be involved in ops as well. But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space. (Insert joke about the CNCF technology landscape map.) There's just so many tech/tools/etc. involved that just reasonably "doing the ops stuff" on the side seems way unrealistic. Sometimes I feel that all we've accomplished was job security for legions of consultants.

DerArzt 5y ago
I am sort of with you on the whole: > But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space. At the same time, I am conflicted. I don't care for the toss-it-over-the-wall approach that used to be the norm, but I also don't like having dev's have to take more on than they are capable. In an ideal environment, I would like to see a crashing together of developers and operations people on teams. What I mean is that for a given team you have several developers and one or two ops folks. This way there is less of an us vs them sentiment and teams can be held accountable for their solutions from ideation to running in production. Finally while it's not the sole responsibility of the dev's to manage their DevOps stuff, they will have more knowledge of how it works, and get to put input and ideas to it.
- geekbird 5y ago
  This was the original intent of DevOps - a cultural shift that put sysadmins/ops people into the dev team, thus have a better feedback loop between dev and prod, and tear down the wall between dev and ops. But now it's being used as a way to eliminate ops people and push it all into dev.