11 ms·

> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. R

> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.

mandelbrotwurst 4y ago
Equally common I think are engineers who care where and how things run, but are either disincentivized from or even disallowed from working on those aspects of systems.
hden 4y ago
Sounds like a cultural problem and/or hiring problem.
dunno7456 4y ago
> There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster. Spot on, but not only that, also decisions made based on number of hands in a room.
lucasyvas 4y ago
It is more nuanced. I care, but my skillset demands I spend more time on the Development side, so Operations must take the backseat in my mind because of this incentive structure. Asking one person to do two (actually three) job functions is a scam. Most developers have to do Frontend, Backend, and Ops. These have wildly different mindsets and feedback loops and not enough time exists. Don't hate the player, hate the game. The orgs are fucked, not the workers.
- makestuff 4y ago
  It is like your doctor being the anesthesiologist, the recovery room nurse, and the surgeon all at once.
  - hbarka 4y ago
    Bad analogy. How about your mom asking you to help wash the dishes and take out the garbage?
    - wruza 4y ago
      She doesn't impose multiple business-critical schedules on that, so you can just wash them, pick your nose for a while, take out the garbage and go play games. There is nothing wrong with doing related jobs solo when situation allows, but this example is also far from learning and using "modern" full-stack of stacks or doing surgeries.
    - makestuff 4y ago
      Well I didn't have to get an education to do that and if I mess up washing the dishes I didn't cause a death in the case of a doctor or a multi million dollar outage in tech.
    - Smaug123 4y ago
      That is an extremely bad analogy. The purpose of chores is to spread the load onto an otherwise unproductive member of the household. (And to teach said household member how to do them.) Unless you're arguing that engineers are unproductive members of a company, I suppose.
  - danielvaughn 4y ago
    Thank you, yes this is the perfect analogy. I think every developer should have some kind of baseline understanding of devops stuff. But it’s a whole field in and of itself, and is also innovating fairly rapidly. There are only so many hours in the day, it’s hard enough to stay on top of my core skill set.
  - dilyevsky 4y ago
    Race car driver vs bus driver. Race car driver knows how their car functions and works with engineers/mechanics on improvements. Bus driver don’t give a shit (no offense to bus driver). Decide which company you are - a race team or a bus line
- jayd16 4y ago
  I think the argument is that calling ops different is like saying error handling is another department. To be a complete dev you must understand the code in situ regardless of your specialty.
- lolinder 4y ago
  > Asking one person to do two (actually three) job functions is a scam. The word "scam" is overused. It's a scam if it was a bait-and-switch. It's not a scam if it was advertised this way up front. In the latter case it's just a job whose description you don't like.
  - lucasyvas 4y ago
    It is a scam. It should absolutely be assumed that you could perform these job functions - it makes you a way better engineer! But being expected to is a scam because the skill ceiling on each is so amazingly high that only a scam artist would expect someone to be able to perform all three to a specialist level. The same issue happened when QA departments got the boot. I deeply understand testing strategies (both manual and automated) but this is an important enough job that it deserves a dedicated person. Not having this person is exclusively because the business is trying to save money and make the worker easily replaceable. It is not better for the department members or the software itself. It is only good for the bottom line. Yes, if you know it all you'll be valued higher - but the company is still reaping the majority of that benefit from you and not rewarding you with 3 salaries. You should not perform all the roles because it's economically idiotic to do so. You could contract out all 3 services and make a shit ton more money than you would performing them in a salaried position. That is a scam.
    - lolinder 4y ago
      I perform all three roles for one company. I agreed to it upfront. I do it in less than 40 hours a week at a very respectable salary. I get maybe 1 after hours call a year for an Ops task. My boss knows that I won't do QA or Ops nearly as well as I do Dev, and he knows that QA and Ops time come out of Dev time (not personal time) and he's okay with that because that's the stage we're in. If you think that is a scam, I don't know what to tell you.
      - lucasyvas 4y ago
        I do. Ask for more money.
Test0129 4y ago
I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and a single point which all work flows through. Then you don't wander onto a new project only to realize they use $BESPOKE_DEPLOYMENT_METHOD because "it's what we used 6 months ago". Or worse, you don't have a developer playing with a massive, nuclear powered, foot gun like Terraform and accidentally destroying infrastructure. Making DevOps/DevSecOps/$BUZZWORD the responsibility of developers is a cost-cutting measure not a responsibility measure.
- dr-detroit 4y ago
- mikkergp 4y ago
  It just doesn't work for the most part. Maybe as an Ops person, I just want to do Ops, I don't want to have to understand your code, but Lambda has specific limitations on how long code can run for. I can't allocate CPU and Memory resources in Kubernetes without a deep understanding of the application. S3 has limitations on how files can be distributed and accessed. Integrating with CI gets complicated quickly and requires understanding the code being integrated. A lot of the time building things in terraform I spend three times as much time getting the information out of a developer as they would doing it themselves. I mean yes, there's 60% or so of my job that involves working on lower level infrastructure that doesn't touch a dev, and we do need ops engineers for that, but the other 40%? It works both ways, a good "devops engineer" needs to understand code, but if we don't have a shared language we both just end up banging our heads against the wall. If you're building a crud-app in a common framework with low volume, sure you can toss that over the wall.
  - Test0129 4y ago
    At companies I've worked for where they actually do this the DevOps people are generally assigned to a team. So you might have 10 developers on a project, and one guy managing just the devops exactly to solve this problem. In smaller companies/etc I can see where this is a problem. I agree, and there's nothing wrong with knowledge sharing. This could even be as simple as having PR descriptions including benchmarks/code/etc and making sure the devops people make their points clear during design/planning. In theory, devops shouldn't be responsible for maintaining the performance of code. The specification should say what it should run on, the devops guys set up a pipeline and manage that thing, and the developers are the ones taking heat for not hitting that goal. If devops guys are taking the heat for that it sounds more like cost-cutting measures flowing the other direction.
williamcotton 4y ago
Well what about Google Sheets? Lots of people are able to build things in Google Sheets without knowing where and how it runs. Perhaps most of our organizations are using the wrong tools and that the way we divide responsibilities is the problem. Imagine if: 1.) instead of general purpose languages being used by product developers we had domain-specific languages and tooling that were agnostic to things like deployment, memory-management, data storage 2.) computer engineers built the domain-specific languages and tooling and focused on things like deployment, memory-management and data storage. DevOps is generally solving for general purpose development while developers are generally solving domain-specific problems with general purpose tools. This seems to be a large part of the disconnect!
- sicp-enjoyer 4y ago
  That's an interesting idea. I wonder what constraints led us to the current division of labor, and which ones are artificial.
  - williamcotton 4y ago
    I have no idea! I’m currently working on a small team of computer engineers who support a custom Turing-complete DSL for an “operations” team that both programs and directly interfaces with clients. It doesn’t seem that different from what Apple or Microsoft do, which is write custom languages and tools for developing on their platforms, albeit specifically for general purpose programming.
wry_discontent 4y ago
I totally don't want to do operations work. I've done some, and it feels like reading an arcane text in another language. I've seen the thing I want before, so I know there exists a magical YAML incantation that brings it about but I have no idea how to even start looking for it. It devolves to an extremely slow feedback loop of "did that work? No." I've never found anything that explained how I'm supposed to create a systematic approach to creating anything I need.
- sgarland 4y ago
  Can't the exact same argument be made for code, though? "That didn't work, and the traceback (if I read it) isn't very helpful. Guess I'll try something else I found on SO." You learn ops by doing it, preferably in an environment where when you inevitably do it wrong, it doesn't break prod.
  - kazen44 4y ago
    The barrier for learning ops is also far higher then learning devs, especially if one wants to get into the industry. Starting in development requires a laptop. Starting with operations requires a datacenter worth of hardware and applications.
alexjplant 4y ago
Sometimes the engineers _do_ care about the deployment and operations of their apps and management doesn't let them administer them in production under the guise of "separation of responsibilities" or "regulatory compliance". It makes the ops team unhappy that they're on the hook for stuff they didn't build and the dev team unhappy because they're steering their metaphorical ship by proxy. I'm not sure why this happens but it does and I don't like it (as somebody who's very M-shaped).
- kbenson 4y ago
  It's because often your software engineers know software development and just enough administration and operations to be dangerous, and your administrators know operations and just enough software development to be dangerous. Letting them wade into others responsibilities often introduces a lot of that danger. System administration is an entire discipline with a history and way of thinking and approaching problems at a systems level. Software engineering is the same, but with an approach that often emphasizes handling problems in the application. Letting solutions be put into applications that are best handled at the system level (where system isn't just an OS, but might be a complex network of them), or put into the system when it could easily be handled by the application, caused inefficiency and problems. The solution is to either hire only very accomplished people that can do both and make the right decision of where to put solutions, or hire people that can do one or the other and put them together with a few (maybe one) person that has a good grasp of both and can make executive decisions when the right time and place is for specific solutions (an architect). The latter is easier to hire for.
LaGrange 4y ago
Yup. I basically came here to quote the same line answering with "And I don't want to work with them." Though mind you, the article touches - but doesn't go into - the real reason things go shit. It's not ops, it's not devops, because your knowledge silo can too, and in my experience (that's longer than the writers, lol) _will be_ pressured. If the estimates are consistently too low (because honest ones would render many - maybe most - projects non-viable), the requirements are often bullshit (because otherwise the lies in the estimate would be too obvious, and everyone needs to agree on the lie) and and rewards are not the ones the jobs claims to be (in every workplace, your job is to improve your resume. That's all. That's the only thing that, materially, matters for your career. I can care about software I write, but if anything I end up punished for it) - then no amount of renaming things and shifting org charts around or motivational reading for managers is going to fix that. Nor will a Cloud or latest orchestration software.
BiteCode_dev 4y ago
The architecte and the carpenter can be the same person on a small house, but I don't think it should on a big office building.
erokar 4y ago
You'll spread yourself too thin as a developer if you need to do a lot of ops too. Specialisation is a good thing. You don't want a doctor who brags that she can do heart surgery, perform talk therapy and treat your skin rash. You want someone how knows a lot about your specific problem because she's prioritised it over other things.
rr808 4y ago
You mean people relaxing WFH in a unbelievably great job market dont like being on call 24/7 and supporting random stuff they didn't build. Sounds like we need a recession.
kevin_thibedeau 4y ago
That used to be a separate job called sys admin.
g051051 4y ago
> You have people who build stuff without caring where and how it runs. Why would someone who wants to build stuff not care about where and how it runs? Operational requirements are the same as any other requirements.
bluedino 4y ago
> You have people who build stuff without caring where and how it runs. In the old days, developers would also configure the design of the system it ran on. "Alright, we're going to use some fast CPU front end nodes with smaller, faster disks, and then have a load balancer, our database server is going to have the most RAM, now let's set these resources up on a CDN to serve faster, this memacache server is really going to lighten the load..." I think the idea was to use tools that automatically did all this work for you, but it just ended up creating another tier of people that configure this side of it.
brundolf 4y ago
It's a context-switch. It's a huge, unavoidable context-switch squarely in the middle of your workflow. And those are a recipe for disaster: https://thinkingthrough.substack.com/p/context-switching-cost-more-than https://thinkingthrough.substack.com/p/context-switching-cos...
icedchai 4y ago
It's always been like this. I'm a backend engineer that also does cloud operations / systems administration / network engineering / "devops" work. The job titles have changed, but the truth remains: (most) developers want to develop, not deal with infrastructure.
- quintu5 4y ago
  Agreed. I get a rush from designing a system from the ground up and bringing it to life with all the infra, but only when that's necessary. If it's just a basic CRUD app without any major performance or resiliency requirements, I'm more than happy to do as little of that infra work as is necessary to get it into production and move on with my life.
cr4nberry 4y ago
Where and how it runs can get incredibly complicated. It isn't a matter of not caring about where it runs, but having a finite amount of time
Merad 4y ago
I absolutely care where and how my code runs. And yet I don't give a damn about writing terraform, managing IAM, VPCs, keeping up with backups, upgrades, etc. I want specialists who know what they're doing to deal with that stuff. I'm also not convinced that the average junior or mid level application dev needs to know where or how their stuff beyond some high level concepts (i.e. our app uses auto scaling).
francisofascii 4y ago
Previously we had better division of labor IMHO. 1) UX people (Photoshop, CSS) who made the front-end look nice, 2) Developers (JavaScript, C#, Ruby, Java) who wrote application code and business logic, 3) DBAs who controlled the database, and 4) Sys Admins (Unix, Windows Server) who deployed the built code and ensured it ran correctly and securely in production. Now some of us seem to think this should all be the same discipline, and if you don't care to, you are a bad engineer.
briandon 4y ago
But isn't this the norm in many other fields? The engineers who design automobiles, aircraft, kitchen blenders, etc. aren't expected to maintain and repair the cars, planes, blenders. etc. after they're put into use. They go on to design other products. Architects and construction/civil-engineering firms design and build large structures and then hand them off to others to maintain. Authors generally write a book and then go on to write the next book rather than dedicating themselves to carefully curating a list of errata for a single book. There are academic authors who do play a part in churning out new, slightly modified editions of major textbooks every few years but they're not on-call and being woken up in the middle of the night to fix a punctuation error on page 982 of the physics text they co-authored.

> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.

mandelbrotwurst 4y ago

Equally common I think are engineers who care where and how things run, but are either disincentivized from or even disallowed from working on those aspects of systems.

hden 4y ago

Sounds like a cultural problem and/or hiring problem.

dunno7456 4y ago

> There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster. Spot on, but not only that, also decisions made based on number of hands in a room.

lucasyvas 4y ago

It is more nuanced. I care, but my skillset demands I spend more time on the Development side, so Operations must take the backseat in my mind because of this incentive structure. Asking one person to do two (actually three) job functions is a scam. Most developers have to do Frontend, Backend, and Ops. These have wildly different mindsets and feedback loops and not enough time exists. Don't hate the player, hate the game. The orgs are fucked, not the workers.

makestuff 4y ago
It is like your doctor being the anesthesiologist, the recovery room nurse, and the surgeon all at once.
- hbarka 4y ago
  Bad analogy. How about your mom asking you to help wash the dishes and take out the garbage?
  - wruza 4y ago
    She doesn't impose multiple business-critical schedules on that, so you can just wash them, pick your nose for a while, take out the garbage and go play games. There is nothing wrong with doing related jobs solo when situation allows, but this example is also far from learning and using "modern" full-stack of stacks or doing surgeries.
  - makestuff 4y ago
    Well I didn't have to get an education to do that and if I mess up washing the dishes I didn't cause a death in the case of a doctor or a multi million dollar outage in tech.
  - Smaug123 4y ago
    That is an extremely bad analogy. The purpose of chores is to spread the load onto an otherwise unproductive member of the household. (And to teach said household member how to do them.) Unless you're arguing that engineers are unproductive members of a company, I suppose.
- danielvaughn 4y ago
  Thank you, yes this is the perfect analogy. I think every developer should have some kind of baseline understanding of devops stuff. But it’s a whole field in and of itself, and is also innovating fairly rapidly. There are only so many hours in the day, it’s hard enough to stay on top of my core skill set.
- dilyevsky 4y ago
  Race car driver vs bus driver. Race car driver knows how their car functions and works with engineers/mechanics on improvements. Bus driver don’t give a shit (no offense to bus driver). Decide which company you are - a race team or a bus line
jayd16 4y ago
I think the argument is that calling ops different is like saying error handling is another department. To be a complete dev you must understand the code in situ regardless of your specialty.
lolinder 4y ago
> Asking one person to do two (actually three) job functions is a scam. The word "scam" is overused. It's a scam if it was a bait-and-switch. It's not a scam if it was advertised this way up front. In the latter case it's just a job whose description you don't like.
- lucasyvas 4y ago
  It is a scam. It should absolutely be assumed that you could perform these job functions - it makes you a way better engineer! But being expected to is a scam because the skill ceiling on each is so amazingly high that only a scam artist would expect someone to be able to perform all three to a specialist level. The same issue happened when QA departments got the boot. I deeply understand testing strategies (both manual and automated) but this is an important enough job that it deserves a dedicated person. Not having this person is exclusively because the business is trying to save money and make the worker easily replaceable. It is not better for the department members or the software itself. It is only good for the bottom line. Yes, if you know it all you'll be valued higher - but the company is still reaping the majority of that benefit from you and not rewarding you with 3 salaries. You should not perform all the roles because it's economically idiotic to do so. You could contract out all 3 services and make a shit ton more money than you would performing them in a salaried position. That is a scam.
  - lolinder 4y ago
    I perform all three roles for one company. I agreed to it upfront. I do it in less than 40 hours a week at a very respectable salary. I get maybe 1 after hours call a year for an Ops task. My boss knows that I won't do QA or Ops nearly as well as I do Dev, and he knows that QA and Ops time come out of Dev time (not personal time) and he's okay with that because that's the stage we're in. If you think that is a scam, I don't know what to tell you.
    - lucasyvas 4y ago
      I do. Ask for more money.

Test0129 4y ago

I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and a single point which all work flows through. Then you don't wander onto a new project only to realize they use $BESPOKE_DEPLOYMENT_METHOD because "it's what we used 6 months ago". Or worse, you don't have a developer playing with a massive, nuclear powered, foot gun like Terraform and accidentally destroying infrastructure. Making DevOps/DevSecOps/$BUZZWORD the responsibility of developers is a cost-cutting measure not a responsibility measure.

dr-detroit 4y ago
mikkergp 4y ago
It just doesn't work for the most part. Maybe as an Ops person, I just want to do Ops, I don't want to have to understand your code, but Lambda has specific limitations on how long code can run for. I can't allocate CPU and Memory resources in Kubernetes without a deep understanding of the application. S3 has limitations on how files can be distributed and accessed. Integrating with CI gets complicated quickly and requires understanding the code being integrated. A lot of the time building things in terraform I spend three times as much time getting the information out of a developer as they would doing it themselves. I mean yes, there's 60% or so of my job that involves working on lower level infrastructure that doesn't touch a dev, and we do need ops engineers for that, but the other 40%? It works both ways, a good "devops engineer" needs to understand code, but if we don't have a shared language we both just end up banging our heads against the wall. If you're building a crud-app in a common framework with low volume, sure you can toss that over the wall.
- Test0129 4y ago
  At companies I've worked for where they actually do this the DevOps people are generally assigned to a team. So you might have 10 developers on a project, and one guy managing just the devops exactly to solve this problem. In smaller companies/etc I can see where this is a problem. I agree, and there's nothing wrong with knowledge sharing. This could even be as simple as having PR descriptions including benchmarks/code/etc and making sure the devops people make their points clear during design/planning. In theory, devops shouldn't be responsible for maintaining the performance of code. The specification should say what it should run on, the devops guys set up a pipeline and manage that thing, and the developers are the ones taking heat for not hitting that goal. If devops guys are taking the heat for that it sounds more like cost-cutting measures flowing the other direction.

williamcotton 4y ago

Well what about Google Sheets? Lots of people are able to build things in Google Sheets without knowing where and how it runs. Perhaps most of our organizations are using the wrong tools and that the way we divide responsibilities is the problem. Imagine if: 1.) instead of general purpose languages being used by product developers we had domain-specific languages and tooling that were agnostic to things like deployment, memory-management, data storage 2.) computer engineers built the domain-specific languages and tooling and focused on things like deployment, memory-management and data storage. DevOps is generally solving for general purpose development while developers are generally solving domain-specific problems with general purpose tools. This seems to be a large part of the disconnect!

sicp-enjoyer 4y ago
That's an interesting idea. I wonder what constraints led us to the current division of labor, and which ones are artificial.
- williamcotton 4y ago
  I have no idea! I’m currently working on a small team of computer engineers who support a custom Turing-complete DSL for an “operations” team that both programs and directly interfaces with clients. It doesn’t seem that different from what Apple or Microsoft do, which is write custom languages and tools for developing on their platforms, albeit specifically for general purpose programming.

wry_discontent 4y ago

I totally don't want to do operations work. I've done some, and it feels like reading an arcane text in another language. I've seen the thing I want before, so I know there exists a magical YAML incantation that brings it about but I have no idea how to even start looking for it. It devolves to an extremely slow feedback loop of "did that work? No." I've never found anything that explained how I'm supposed to create a systematic approach to creating anything I need.

sgarland 4y ago
Can't the exact same argument be made for code, though? "That didn't work, and the traceback (if I read it) isn't very helpful. Guess I'll try something else I found on SO." You learn ops by doing it, preferably in an environment where when you inevitably do it wrong, it doesn't break prod.
- kazen44 4y ago
  The barrier for learning ops is also far higher then learning devs, especially if one wants to get into the industry. Starting in development requires a laptop. Starting with operations requires a datacenter worth of hardware and applications.

alexjplant 4y ago

Sometimes the engineers _do_ care about the deployment and operations of their apps and management doesn't let them administer them in production under the guise of "separation of responsibilities" or "regulatory compliance". It makes the ops team unhappy that they're on the hook for stuff they didn't build and the dev team unhappy because they're steering their metaphorical ship by proxy. I'm not sure why this happens but it does and I don't like it (as somebody who's very M-shaped).

kbenson 4y ago
It's because often your software engineers know software development and just enough administration and operations to be dangerous, and your administrators know operations and just enough software development to be dangerous. Letting them wade into others responsibilities often introduces a lot of that danger. System administration is an entire discipline with a history and way of thinking and approaching problems at a systems level. Software engineering is the same, but with an approach that often emphasizes handling problems in the application. Letting solutions be put into applications that are best handled at the system level (where system isn't just an OS, but might be a complex network of them), or put into the system when it could easily be handled by the application, caused inefficiency and problems. The solution is to either hire only very accomplished people that can do both and make the right decision of where to put solutions, or hire people that can do one or the other and put them together with a few (maybe one) person that has a good grasp of both and can make executive decisions when the right time and place is for specific solutions (an architect). The latter is easier to hire for.

LaGrange 4y ago

Yup. I basically came here to quote the same line answering with "And I don't want to work with them." Though mind you, the article touches - but doesn't go into - the real reason things go shit. It's not ops, it's not devops, because your knowledge silo can too, and in my experience (that's longer than the writers, lol) _will be_ pressured. If the estimates are consistently too low (because honest ones would render many - maybe most - projects non-viable), the requirements are often bullshit (because otherwise the lies in the estimate would be too obvious, and everyone needs to agree on the lie) and and rewards are not the ones the jobs claims to be (in every workplace, your job is to improve your resume. That's all. That's the only thing that, materially, matters for your career. I can care about software I write, but if anything I end up punished for it) - then no amount of renaming things and shifting org charts around or motivational reading for managers is going to fix that. Nor will a Cloud or latest orchestration software.

BiteCode_dev 4y ago

The architecte and the carpenter can be the same person on a small house, but I don't think it should on a big office building.

erokar 4y ago

You'll spread yourself too thin as a developer if you need to do a lot of ops too. Specialisation is a good thing. You don't want a doctor who brags that she can do heart surgery, perform talk therapy and treat your skin rash. You want someone how knows a lot about your specific problem because she's prioritised it over other things.

rr808 4y ago

You mean people relaxing WFH in a unbelievably great job market dont like being on call 24/7 and supporting random stuff they didn't build. Sounds like we need a recession.

kevin_thibedeau 4y ago

That used to be a separate job called sys admin.

g051051 4y ago

> You have people who build stuff without caring where and how it runs. Why would someone who wants to build stuff not care about where and how it runs? Operational requirements are the same as any other requirements.

bluedino 4y ago

> You have people who build stuff without caring where and how it runs. In the old days, developers would also configure the design of the system it ran on. "Alright, we're going to use some fast CPU front end nodes with smaller, faster disks, and then have a load balancer, our database server is going to have the most RAM, now let's set these resources up on a CDN to serve faster, this memacache server is really going to lighten the load..." I think the idea was to use tools that automatically did all this work for you, but it just ended up creating another tier of people that configure this side of it.

brundolf 4y ago

It's a context-switch. It's a huge, unavoidable context-switch squarely in the middle of your workflow. And those are a recipe for disaster: https://thinkingthrough.substack.com/p/context-switching-cost-more-than https://thinkingthrough.substack.com/p/context-switching-cos...

icedchai 4y ago

It's always been like this. I'm a backend engineer that also does cloud operations / systems administration / network engineering / "devops" work. The job titles have changed, but the truth remains: (most) developers want to develop, not deal with infrastructure.

quintu5 4y ago
Agreed. I get a rush from designing a system from the ground up and bringing it to life with all the infra, but only when that's necessary. If it's just a basic CRUD app without any major performance or resiliency requirements, I'm more than happy to do as little of that infra work as is necessary to get it into production and move on with my life.

cr4nberry 4y ago

Where and how it runs can get incredibly complicated. It isn't a matter of not caring about where it runs, but having a finite amount of time

Merad 4y ago

I absolutely care where and how my code runs. And yet I don't give a damn about writing terraform, managing IAM, VPCs, keeping up with backups, upgrades, etc. I want specialists who know what they're doing to deal with that stuff. I'm also not convinced that the average junior or mid level application dev needs to know where or how their stuff beyond some high level concepts (i.e. our app uses auto scaling).

francisofascii 4y ago

Previously we had better division of labor IMHO. 1) UX people (Photoshop, CSS) who made the front-end look nice, 2) Developers (JavaScript, C#, Ruby, Java) who wrote application code and business logic, 3) DBAs who controlled the database, and 4) Sys Admins (Unix, Windows Server) who deployed the built code and ensured it ran correctly and securely in production. Now some of us seem to think this should all be the same discipline, and if you don't care to, you are a bad engineer.

briandon 4y ago

But isn't this the norm in many other fields? The engineers who design automobiles, aircraft, kitchen blenders, etc. aren't expected to maintain and repair the cars, planes, blenders. etc. after they're put into use. They go on to design other products. Architects and construction/civil-engineering firms design and build large structures and then hand them off to others to maintain. Authors generally write a book and then go on to write the next book rather than dedicating themselves to carefully curating a list of errata for a single book. There are academic authors who do play a part in churning out new, slightly modified editions of major textbooks every few years but they're not on-call and being woken up in the middle of the night to fix a punctuation error on page 982 of the physics text they co-authored.