It’s a poor “senior” software engineer who doesn’t understand anything about the underlying architecture or how to at least troubleshoot the infrastructure and have at least some type of understanding of the ops part.

How many hardware based Kickstarter projects have failed because they didn’t understand the complexity of actually manufacturing there product at scale.

It’s analogous to software engineers who don’t appreciate ops. Writing software for a company is useless if you can’t ship it or deploy it. You can’t imagine the number of bright eyed bushy tailed “software engineers” I’ve dealt with that thought they were smart because they knew leetCode and learned algorithms who couldn’t troubleshoot performance issues or understand why they couldn’t get shipping products because they didn’t understand the ops side of things.

Of course I am not diminishing the role of software engineering, I’ve been developing software actively professionally or as a hobby for over 30 years. But, I know enough in theory to talk to the ops guys for on prem/colo/hybrid architectures and I could easily be competitive on the ops side for jobs dealing with fully “cloud native” solutions for a small to medium size implementation.

> Software engineering is about writing code, devops is about writing yaml files and keying into functionality that was implemented by software engineers.

This attitude is the ultimate reason for dysfunctional development teams and the source of the barrier between operations and development.

It’s also toxic.

I work in devops (and did so before it was called that), I write code in turing complete languages. Just code that manages infrastructure and software rather then interacts directly with end users. I template configuration files rather then user interfaces. I have to consider race conditions in complex systems, consider the robustness and security implications of anything I do, verify my input (that's you, you hotshot "software engineer") and fail gracefully if needed.

Tell me that is not software engineering, the only difference is that my ability to test before deployment is much more costly and limited, I have to get it right the first time around..

Describing ops as “writing yaml files” is like describing software engineering as “typing.”

> Software engineering is about writing code, devops is about writing yaml files and keying into functionality that was implemented by software engineers.

Creating these strict barriers between teams, especially with the condescension you elicit is exactly how problems arise.

Suppose software engineers write an O(N^2) algorithm because they didn't think the data would grow large. It does. DevOps then launches many more dozens of computers to handle the algorithm. If no one speaks to eachother, everyone thinks things are going smoothly when in reality it's a complete disaster. The DevOps team has much more visibility into the usage, performance, and cost of apps than many developers. Talk to your breathen wisely.

I pivoted a couple of years ago from SE to DevOps, and the latter has been far more complex in my experience.

Probably most importantly, my experience on DevOps has been a bit like hurried product management and software engineering work--I have to identify problems and opportunities to improve software development efficiency, uptime, etc and find/build technologies that solve those problems, and all of these technology choices are really complicated because they are interdependent. How you structure your CI/CD pipeline depends a lot on your orchestration platform (and vice versa). It also depends on whether you use micro services or a monolith, and whether your platform is mono/bi-lingual or fully multilingual. And unlike product management or software engineering, you have to deliver value in a much tighter timeframe (you don't get to spend a year building out a solution with budget and resources for user testing, QA, etc). Further, if you think the frontend web stack is changing fast, the DevOps world will make your head spin!

Regarding YAML, it's just the (currently popular) interface; it doesn't say anything about the amount of complexity. It was originally YAML/JSON because everyone thought it would be super simple configuration, but virtually every infrastructure-as-code (IaC) tool is moving away from YAML to something more powerful.

AWS has CloudFormation which began as JSON/YAML with features hacked on to support things like referencing other nodes in the document, defining and calling functions and macros, evaluating conditionals, looking up values in maps, etc. Now they're building the Cloud Development Kit (CDK) to let developers write IaC in languages like Python and TypeScript, because even the extensions to CloudFormation are insufficient (no ability to pass around parameters, pass structured data, perform computations, etc).

I don't use Terraform, but I understand HCL started out a lot like YAML but is also becoming increasingly powerful with each release.

Helm also started with YAML but is adding in Lua.

The argument that DevOps is easier than SE because it's just using tools created by SEs is silly on its face. First of all, those tools were _implemented_ by SEs but created by much larger teams, including product managers. Secondly, "SEs" are also just using tools created by SEs--compilers, interpreters, VMs, build tools, etc. Not to mention all of the tools and processes built and/or assembled by DevOps engineers.

So would you consider it more “software engineering” using AWS’s Cloud Development Kit and writing code to generate cloud formation files “software engineering”?

I use to think that all “true” developers needed to know the ins and outs of assembly because every time I went to a new platform that’s the first thing that I did - learn assembly language (65C02, 68K, x86), but then I grew up.....

CloudFormation takes a text file and generates API calls much like any code compiled down to assembly.

You could say the same thing about software engineering. The vast majority of it is simply assembling components that already exist. I've worked on dozens if not hundreds of web apps, and most of it is just gluing stuff together. Often it's done on autopilot (or literally automated code generation). I've also worked on a lot of code that was original and challenging. Systems work is the same thing. Most of the time you're just assembling existing components, but the overall design of the system is absolutely engineering.

Right, just like telescope building is about making lenses and hollow tubes, astronomy is about looking at the sky and keying into the functionality that was implemented by telescope makers.

I believe you would benefit from a different perspective because this vision is partial at best. The distinction between who builds system and tools and who uses them is subtle and often these roles are interchangeable. Both have dignity and purpose and contribute to the goal, regardless of the collar color, which is a remnant of the last century.

Galileo built his own telescopes.

Dude, the yaml files I'm writing require good knowledge of the system they are configuring.

i deploy all our cloud instances using Ansible (yml files) and I wouldn't have a hope of doing that if I didn't understand the OS I'm configuring with it (Linux).

I might see your point if you're talking about the yml that is used to configure 'value added' products from cloud vendors, but I avoid those like the expensive handcuffs that they are.

Where does code begin and end - I do work that could be described as devops, and I'm often writing python or bash to do something work related - according GP (and by extension, you.), I'm just a blue collar grunt