building data centers, maintaining databases, designing data structures, and many things more.

This is what I know about software development:

This is the https://en.wikipedia.org/wiki/Theatre_of_Marcellus in Rome, built in 13BC. It was used for 400 years as a theatre. Then it was a quarry, a fortress, a noble residence, and now it is appartments and a small venue for Hipster concerts.

When we educate software developers in University, and when we hire them into the Enterprise, we talk to them about Development as if we were building a Mall on a green lawn in front of the City.

But actual cities and actual construction is not like this at all. They are like the Theatre of Marcellus instead: Old structures, ill fitting for the purpose, inherited across the centuries and repurposed and refitted for thousands of years.

Everything is always brown field with 2000 years of history (read: rubble) and existing infra around it. Which is being used and cannot be disturbed by construction without inconveniencing others and endangering vital money streams.

This is your job as a software developer in reality.

All software development in the field is exactly like this.

There are always existing systems that do not fit exactly, but which you are dependent on.

There is always an existing system your code has to fit into.

And there is always existing code into which you must fit, which you must replace, in a bug compatible way, or which you are supposed to refactor.

There are always borderline real world cases that ruin your streamlined architecture.

So 90% of your work is archeology, classification of technical debt and refactoring or non-interrupting replacement.

This *is* what software development actually *is*.

We lied to you in University, and again in the hiring interview.

So Devops:

The dev part is "changing what is already there" to make it fit.

The ops part is "not disturbing the money streams" while you do this, and keeping the city alive around you.

There is also a Fedora and a Whip, as well as a very small pick and a toothbrush, and no map.

This is what you need to identify the actual stakeholders, extract the actual requirements, and to find the missing documentation.

Sometimes there is Dynamite. Far too rarely, though.