4 ms·

From what I've seen recently is the inverse of that. There are scores of developers who have little understanding of OS scaffolding or networking, but are good

From what I've seen recently is the inverse of that. There are scores of developers who have little understanding of OS scaffolding or networking, but are good at writing merge sorts in Python. Most Devops people I know are not the ones pushing "vanguard of a new paradigm" BS, they are just ops who can code and understand performance tradeoffs, networking, subsystems, etc. I guess we can blame Devops for one thing, the paradigm has encouraged the behavior of "real devs" (TM) not understanding anything about the underlying platforms they are writing code for. That was the point, but it's not all gravy.

jon-wood 3y ago
> That was the point, but it's not all gravy. [Weeps] That wasn’t the point, the point was exactly the opposite of that, to get developers and ops working as a single team, building an understanding of each other’s domain in order to make things better. Sadly the point was lost long ago, and devops engineers and devops teams have taken the place sysadmins and ops teams in providing a nice little silo you can chuck your terrible code over the wall at and not have to think about how it works.
- threetonesun 3y ago
  Yep, you can think of it as overlapping circles in a Venn diagram, or if you prefer T-shaped people, imagine an entire 4-row block in Tetris. How do you fill out expertise in the entire domain but also have broad knowledge of it across the team. The business side hates it because people with expertise aren't interchangeable widgets they can throw at any problem.
- darkwater 3y ago
  This. But you know what? There are tons of developers who are _perfectly fine with this_! There are tons of developers who just want to write business code in their CRUD webapp and call it a day, the more abstractions you can give them, the happier they are. And while I don't like it, I don't blame them.
  - JohnMakin 3y ago
    assuming the code is reasonable and can scale they should be allowed to and enabled to do this. as a dev I dont want to think too hard about the infrastructure underneath it, I just want it to run. the ole “runs on local therefore it’s good to go” should be good enough.
    - Tainnor 3y ago
      You can ignore some of the details, but you can't ignore everything. Which database you choose and how you scale it will affect your application code. You can't write code that makes use of the local file system (or in-memory data for anything meant to be persistent) if you have more than one container serving your app. (And yes, some people need to be explicitly taught not to do that.) And so on.
  - jon-wood 3y ago
    Absolutely agreed, and if they have to think particularly hard about things outside their application space for a CRUD web app then either you’re in an extraordinarily high throughput environment, or the platform engineering needs a bit more work to abstract things away. That’s the ideal outcome here, developers can develop, and when they’re done they hit the Deploy button and off it goes. Where this falls down is when development teams are building complex systems and then expecting the ops team to divine how that’s meant to work in production.
  - wizofaus 3y ago
    Do you dislike it when application developers don't think about the way CPUs work at the silicon level? Or the way TCP/IP works under the hood (handling packet ordering/ connection negotiation etc.)? It's not immediately obvious to me that an application developer should have to worry too much about how their software is delivered/hosted etc., though I'd certainly agree that understanding it better generally makes you a better developer. And that the reality of modern O/S's and hosting platforms still means that implementation details inevitably leak their way into application space, unfortunately.

jon-wood 3y ago

> That was the point, but it's not all gravy. [Weeps] That wasn’t the point, the point was exactly the opposite of that, to get developers and ops working as a single team, building an understanding of each other’s domain in order to make things better. Sadly the point was lost long ago, and devops engineers and devops teams have taken the place sysadmins and ops teams in providing a nice little silo you can chuck your terrible code over the wall at and not have to think about how it works.

threetonesun 3y ago
Yep, you can think of it as overlapping circles in a Venn diagram, or if you prefer T-shaped people, imagine an entire 4-row block in Tetris. How do you fill out expertise in the entire domain but also have broad knowledge of it across the team. The business side hates it because people with expertise aren't interchangeable widgets they can throw at any problem.
darkwater 3y ago
This. But you know what? There are tons of developers who are _perfectly fine with this_! There are tons of developers who just want to write business code in their CRUD webapp and call it a day, the more abstractions you can give them, the happier they are. And while I don't like it, I don't blame them.
- JohnMakin 3y ago
  assuming the code is reasonable and can scale they should be allowed to and enabled to do this. as a dev I dont want to think too hard about the infrastructure underneath it, I just want it to run. the ole “runs on local therefore it’s good to go” should be good enough.
  - Tainnor 3y ago
    You can ignore some of the details, but you can't ignore everything. Which database you choose and how you scale it will affect your application code. You can't write code that makes use of the local file system (or in-memory data for anything meant to be persistent) if you have more than one container serving your app. (And yes, some people need to be explicitly taught not to do that.) And so on.
- jon-wood 3y ago
  Absolutely agreed, and if they have to think particularly hard about things outside their application space for a CRUD web app then either you’re in an extraordinarily high throughput environment, or the platform engineering needs a bit more work to abstract things away. That’s the ideal outcome here, developers can develop, and when they’re done they hit the Deploy button and off it goes. Where this falls down is when development teams are building complex systems and then expecting the ops team to divine how that’s meant to work in production.
- wizofaus 3y ago
  Do you dislike it when application developers don't think about the way CPUs work at the silicon level? Or the way TCP/IP works under the hood (handling packet ordering/ connection negotiation etc.)? It's not immediately obvious to me that an application developer should have to worry too much about how their software is delivered/hosted etc., though I'd certainly agree that understanding it better generally makes you a better developer. And that the reality of modern O/S's and hosting platforms still means that implementation details inevitably leak their way into application space, unfortunately.