7 ms·

This is widespread unfortunately. Developers changed to „users” and no longer pursue the details of solutions. Im not gonna say its the dominant behaviour in th

by pojzon 7y ago

This is widespread unfortunately. Developers changed to „users” and no longer pursue the details of solutions. Im not gonna say its the dominant behaviour in the field right now, but I see it more and more often on various experience levels.

jagged-chisel 7y ago
An experienced software engineer (yeah, developer) has experience engineering software. It’s been less than 10yrs since the advent of containerized deployments, and the space has been fraught with change nearly on par with the front end JavaScript ecosystem. Might as well just stick to writing code. OK, that’s the perception of my own peers, but I assume it scales. DevOps is a recent advent, too, and sounds to me like it should be populated with folks who can participate in development and operations. Most developers I’ve ever known aren’t interested in operations.
- dielectrikboog 7y ago
  SRE was born of putting software engineers to work building operational software and automation tailored to an organization and application. In contrast, no matter what anyone says, DevOps was objectively born of replacing the operations discipline and career track with a poorly-understood tool economy and ongoing opex to a cloud provider. As you say, typical JavaScript engineers can’t be bothered to understand network capacity planning yet feel they are more qualified to take their application to production by deferring all decisions to cloud providers. Who all employ SREs/PEs, not DevOps Engineers, by the way, and there is a big distinction. We have people who can handle the operational stuff. They’re called systems administrators, network engineers, yes, even SREs, and other folks who are really good at understanding how computers and the Internet actually work, and a webdev bootcamp gives zero context into exactly what they do. None. Then, your ten-head startup suddenly scales to needing a physical footprint because it will literally save 80% of opex, and all your DevOps Engineers say “but why? There’s AWS,” and you’re in Medium hell for weeks arguing about it. Apropos, if I interview you and find you have written a thoughtpiece on Medium about how “sysadmin is evolving” and it’s “time for the gray beards to learn code,” you do not get a call back. That has actually happened, and no, sysadmin is not evolving. I know staff-level “full stack engineers” who can’t tell me what an ASN is. The motions in the industry have merely made those people more in demand at a few companies and served to cement their position as “where computing gets done”. Expect serious, existential operational threats and breaches to rise dramatically as DevOps continues to “win,” and consider it a smart strategic move to avoid DevOps culture in the long term. If you write a req called “DevOps Engineer,” I don’t even know what to say to you.
  - delusional 7y ago
    Has sysadmin not evolved? if I found some sysadmin logging into a production system and editing the config file in nano today, I'd be downright depressed.
    - dielectrikboog 7y ago
      Sounds like you’re going to be depressed when you learn how the entire Internet plane, all software engineering outside of “SV”, all IT, all government, and basically everything except your GitHub CI/CD adventure works, then. Sorry.
      - aprdm 7y ago
        Even within SF. Having talked with a bunch of folks from Amazon and Netflix they're far from having most of their workflows running in containers... imagine is the same for google.
      - jmb12686 7y ago
        This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.
        dielectrikboog 7y ago
        For the better? I’m not asking out of preference, I’m asking out of actual conclusion: is trading the operational overhead of running LDAP for a usually homegrown, usually wobbly automated scripting soufflé that turns Make into a distributed system objectively better? Has nobody stopped to ask, is DevOps and CI/CD the best framework we can achieve? Did nobody think to ask before they told your agency it was the ‘right’ methodology and the objectively best way to build industrial, business process software in the government sector? Did the changing times come from ideology and belief or identified process gaps? I ask because I think there’s something better. I don’t know what it is yet, but I want to find out. I’m worried about wastage in DevOps methodologies, a system where nobody is incentivized to care about the right things, going on to spook the policymakers on doing software before we find out if the DevOps and Cloud worlds, both, are objectively the best way to do software for their purposes. I strongly, strongly feel like the craft is on the wrong path, and persuasive successes in industry are getting to the right ears before we know if the discipline to efficiently handle agile infrastructure with today’s tooling is even possible. I’m not convinced DevOps will organically find the right calculus to spur the kind of systems research that took us to not only where we are, but that which will take us where we need to go. Speaking of, I’m lazily glancing at Agile here as well but I’m not prepared for a coherent argument there, beyond pointing out that we now have better tooling for managing specifications, particularly formal and mathematical ones, than the waterfall development experiences that prompted agile thinking. We need more systems research, tinkering, rethinking POSIX, all of it.
justanotherc 7y ago
You talk as if that's a bad thing. As a developer I don't want to wade into the details of systems I'm using, I want to spend my time writing code that solves the business problems I'm tasked with solving. If there is a system that allows me to do that by abstracting away the details I don't care about, why wouldn't I use that system?
- jschwartzi 7y ago
  Because frequently the devil is in the details.
  - bluGill 7y ago
    But only some of the details. I still need to ignore most of the details even while I need control of the ones that matter. This is easier said than done.
    - justanotherc 7y ago
      Exactly. The large project I'm working on has 100k LOC that I've personally written. However out od curiosity once I ran CLOC on the vendor folder... and it gave up after 2.5 million LOC. I could never possibly understand all the details going on in there lol.
    - jschwartzi 7y ago
      The devil is in the details of the details.
- ben509 7y ago
  I do want to wade into the details, so I'd put it more that I need to try many things, and by necessity I have to be a user before I can become an expert. I know a good deal about how Docker works from having hammered at it. I'm not remotely an expert in it yet, but as I go I'm learning more details about cgroups and namespaces, and this is stuff I've been able to fit in while solving problems.
- legulere 7y ago

by pojzon 7y ago

jagged-chisel 7y ago

An experienced software engineer (yeah, developer) has experience engineering software. It’s been less than 10yrs since the advent of containerized deployments, and the space has been fraught with change nearly on par with the front end JavaScript ecosystem. Might as well just stick to writing code. OK, that’s the perception of my own peers, but I assume it scales. DevOps is a recent advent, too, and sounds to me like it should be populated with folks who can participate in development and operations. Most developers I’ve ever known aren’t interested in operations.

dielectrikboog 7y ago
SRE was born of putting software engineers to work building operational software and automation tailored to an organization and application. In contrast, no matter what anyone says, DevOps was objectively born of replacing the operations discipline and career track with a poorly-understood tool economy and ongoing opex to a cloud provider. As you say, typical JavaScript engineers can’t be bothered to understand network capacity planning yet feel they are more qualified to take their application to production by deferring all decisions to cloud providers. Who all employ SREs/PEs, not DevOps Engineers, by the way, and there is a big distinction. We have people who can handle the operational stuff. They’re called systems administrators, network engineers, yes, even SREs, and other folks who are really good at understanding how computers and the Internet actually work, and a webdev bootcamp gives zero context into exactly what they do. None. Then, your ten-head startup suddenly scales to needing a physical footprint because it will literally save 80% of opex, and all your DevOps Engineers say “but why? There’s AWS,” and you’re in Medium hell for weeks arguing about it. Apropos, if I interview you and find you have written a thoughtpiece on Medium about how “sysadmin is evolving” and it’s “time for the gray beards to learn code,” you do not get a call back. That has actually happened, and no, sysadmin is not evolving. I know staff-level “full stack engineers” who can’t tell me what an ASN is. The motions in the industry have merely made those people more in demand at a few companies and served to cement their position as “where computing gets done”. Expect serious, existential operational threats and breaches to rise dramatically as DevOps continues to “win,” and consider it a smart strategic move to avoid DevOps culture in the long term. If you write a req called “DevOps Engineer,” I don’t even know what to say to you.
- delusional 7y ago
  Has sysadmin not evolved? if I found some sysadmin logging into a production system and editing the config file in nano today, I'd be downright depressed.
  - dielectrikboog 7y ago
    Sounds like you’re going to be depressed when you learn how the entire Internet plane, all software engineering outside of “SV”, all IT, all government, and basically everything except your GitHub CI/CD adventure works, then. Sorry.
    - aprdm 7y ago
      Even within SF. Having talked with a bunch of folks from Amazon and Netflix they're far from having most of their workflows running in containers... imagine is the same for google.
    - jmb12686 7y ago
      This isn't an accurate statement. I work on behalf of a federal government agency, and no one has write access in development, let alone production. Everything is required to run thru our ci/cd pipeline. Times are changing.
      - dielectrikboog 7y ago
        For the better? I’m not asking out of preference, I’m asking out of actual conclusion: is trading the operational overhead of running LDAP for a usually homegrown, usually wobbly automated scripting soufflé that turns Make into a distributed system objectively better? Has nobody stopped to ask, is DevOps and CI/CD the best framework we can achieve? Did nobody think to ask before they told your agency it was the ‘right’ methodology and the objectively best way to build industrial, business process software in the government sector? Did the changing times come from ideology and belief or identified process gaps? I ask because I think there’s something better. I don’t know what it is yet, but I want to find out. I’m worried about wastage in DevOps methodologies, a system where nobody is incentivized to care about the right things, going on to spook the policymakers on doing software before we find out if the DevOps and Cloud worlds, both, are objectively the best way to do software for their purposes. I strongly, strongly feel like the craft is on the wrong path, and persuasive successes in industry are getting to the right ears before we know if the discipline to efficiently handle agile infrastructure with today’s tooling is even possible. I’m not convinced DevOps will organically find the right calculus to spur the kind of systems research that took us to not only where we are, but that which will take us where we need to go. Speaking of, I’m lazily glancing at Agile here as well but I’m not prepared for a coherent argument there, beyond pointing out that we now have better tooling for managing specifications, particularly formal and mathematical ones, than the waterfall development experiences that prompted agile thinking. We need more systems research, tinkering, rethinking POSIX, all of it.

justanotherc 7y ago

You talk as if that's a bad thing. As a developer I don't want to wade into the details of systems I'm using, I want to spend my time writing code that solves the business problems I'm tasked with solving. If there is a system that allows me to do that by abstracting away the details I don't care about, why wouldn't I use that system?

jschwartzi 7y ago
Because frequently the devil is in the details.
- bluGill 7y ago
  But only some of the details. I still need to ignore most of the details even while I need control of the ones that matter. This is easier said than done.
  - justanotherc 7y ago
    Exactly. The large project I'm working on has 100k LOC that I've personally written. However out od curiosity once I ran CLOC on the vendor folder... and it gave up after 2.5 million LOC. I could never possibly understand all the details going on in there lol.
  - jschwartzi 7y ago
    The devil is in the details of the details.
ben509 7y ago
I do want to wade into the details, so I'd put it more that I need to try many things, and by necessity I have to be a user before I can become an expert. I know a good deal about how Docker works from having hammered at it. I'm not remotely an expert in it yet, but as I go I'm learning more details about cgroups and namespaces, and this is stuff I've been able to fit in while solving problems.
legulere 7y ago