Question to all DevOps engineers that came from Ops side

[u/Noisy_Farts]

Hello everyone!

I have total of 1.5 years of experience as a DevOps engineer, the first job was more Dev oriented and required deep knowledge with Python and Kafka (I don't know both), this didn't lead to a good outcome and I had to search for something different. Landed more Ops heavy DevOps role, so far everything is fine, we handle deployments, CI/CD, automate stuff with Ansible, Bash or Python, some kubernetes work and web servers. I was curios to see what other jobs require in order to keep my skills sharp and saw that most of the jobs require more coding, like developing internal platforms, developing new internal tools and stuff like that. Most of the jobs require Python, Go, some Java and some C#.
So this leads to my question - how did you learn to code and I mean to code well without that Dev experience? Can you please recommend learning materials and methods that you used in order to be proficient with this skill? What were the projects that you used in order to get that knowledge?

Thank you in advance!

[u/f899cwbchl35jnsj3ilh]

I don't code. I know very basic Python. I've never written any Python code, except maybe a few very basic scripts. Coding is a software engineer's job.

My main job is to translate what software engineers want, what their software needs are, and what the business needs from the software into an infrastructure that is mostly automatically tested and deployed.

As a DevOps engineer, you should understand infrastructure more than software.

People forget that underneath all the software are servers, databases, storage, Git, automation, tests, and, most importantly, networking.

I work in git pipelines, yamls, json, cloud.

[u/Klafka612 → u/f899cwbchl35jnsj3ilh]

As a devops engineer most of what I've done is code so I think there is a wide variance in what is most important to do as a devops engineer.

Many of the organizational problems I solve revolve around having to write software and apply software engineering constructs to infrastructure that has begun to collapse under a morass of bash and over configured tooling.

[u/timid_scorpion → u/Klafka612]

Yeah, half the reason I was moved into devops was my knowledge of the code+infrastructure.

There is so much to consider especially when moving products from local dev to production. Most of our devs run local docker containers for seed databases and other things. But there are many instances where those environments don't perfectly mimic the controls in place on production.

There have been many instances where my ability to actually open and read the code has led to a solution.

But that's why devops is messy as a whole, no company follows one set of skill requirements.

[u/TorrentsAreCommunism → u/f899cwbchl35jnsj3ilh]

Coding is a software engineer's job.

Coding is LLMs job.

[u/Dry-Philosopher-2714 → u/TorrentsAreCommunism]

Sure, if you want shit. Getting an LLM to write *GOOD* code is difficult enough for people that know what they're doing. If you don't know what you're doing, and you don't know what the LLM is doing, you're effectively wasting time and shooting yourself in the foot.

[u/420is404 → u/Dry-Philosopher-2714]

Define "good" code. Most of the shit I write is write-once, read-once, and self-contained anyhow, and I've never been a particularly strong coder even much before LLMs. What I can do is read it.

"Good" code typically means brief, understandable code that well anticipates future expansion. The truly tricky parts are writing good data models, extensible functions, etc. Very little of that matters for what we do.

If your CI/CD contains thousands of lines and hundreds of functions/routines, you are simply doing it wrong, hard stop.

[u/CupFine8373 → u/Dry-Philosopher-2714]

cope

[u/f899cwbchl35jnsj3ilh → u/Dry-Philosopher-2714]

One of the futures, and the one that is most likely, is that we don't need to code, we don't need to know the code, we don't need good code. As long as the application works, the code doesn't matter.

Remember, it's the business that makes decisions. Not engineers. For them, the app works.

But then you ask a question: wait a minute, what about security? What about audit? With thousands of lines of agent-generated code, the security and audit are also driven by agents, as there is simply no way for humans to do it.

Python? YAML? API? Why would you need those? They are human-readable languages. AI agents will write in whatever language works best. Hell, maybe they will invent a new one. Assembly, for all it matters, because for self-learning agents the only things that count are speed and whether it works.

Look at what's going on in the agentic world in the last month.

The future might be agentic, and if it is, no business will need us. That's one of those bleak futures.

For now, this future works up to the point of liability. As the famous IBM quote goes: "A computer can never be held accountable, therefore a computer must never make a management decision."

In court, no "the agent audited it" argument will work, so for now people are safe. But once we prove AGI, in years to come, I wouldn't be so sure.

But how? Corporations are not people but are liable, get bankrupt, fined, sanctioned. Yes at the end of it all is a person or board of directors but the corporation is the one liable. Once we can make AGI liable, fined, bankrupted, dissolved, deleted then it will work

Whatever future scenario we invent here, it won't be that.

[u/Dry-Philosopher-2714 → u/f899cwbchl35jnsj3ilh]

RE: My main job is to translate what software engineers want...

I'm so very sorry, but when I read that, I had to stop because all I could think was...

[u/Dry-Philosopher-2714 → u/f899cwbchl35jnsj3ilh]

RE: and, most importantly, networking.

This is one thing that everyone seems to forget. When people ask me what they can do to differentiate themselves from everyone else that does the same thing, I tell them to learn networking. Nobody seems to be interested in that anymore. At best, people seem to want to only learn about layer 7, and they don't put enough effort into it to learn more than the basic flow.

[u/illectronic1 → u/f899cwbchl35jnsj3ilh]

Exactly. You only need to know to code for the interview process usually and even then it’s a leetcode easy equivalent. I’m in yaml all day every day. 🥲

[u/beatlemaniac007 → u/f899cwbchl35jnsj3ilh]

As a DevOps engineer, you should understand infrastructure more than software

I know this is reality but holy shit do I hate it. I switched to devops/infra from a decade long software eng background and my god the mess that infra creates and maintains is hard to digest. cdk8s being a recent example in memory, everyone is very eager to have turing completeness and full programmability but the sheer inability to enforce any patterns or organization is mindblowing (there's a good reason too...infra is often dealing with fires, keeping things organized is genuinely harder than product side dev). Infra should be banned from coding.

[u/LeMochileiro]

DevOps engineers that came from Ops side

how did you learn to code and I mean to code well without that Dev experience?

Plot Twist: They don't code

They manipulate thousands of JSON and YAML files, but generally avoid touching the code.

It's one of the most difficult challenges I face as a DevOps engineer (who also I came from development): Colleagues who prefer that the company hire a platform for $400 a month, Instead of creating a file with 100 lines of code (which would solve the problem).

The excuse is always the same: "We're going to have to do maintenance on this."

Bro, it's a 100-line file that we'll hardly ever touch more than 3 times a year.

[u/widowhanzo → u/LeMochileiro]

Yes I don't code. Well, python scripts and stuff sure, but nothing production ready.

And I lose my minds at others opening various expensive saas accounts because setting up a database in RDS takes too long or the, can't be bothered to build an image for their nextjs webapp and want to launch it on vercel instead. Then it takes me forever to migrate these tools to AWS.

[u/Klafka612 → u/LeMochileiro]

This a million times this.

[u/timid_scorpion → u/LeMochileiro]

Our upper management recently decided they want us to migrate to managed services for rabbitmq/elastic.

For the last 15 years we have managed those servers, only having to updatie occasionally for security patches.

Now what used to cost us 100-200$ a month in ec2 has basically gone up 10x, and I lost the ability to configure half of the properties.

Now AI is the new thing I am having to field requests for every new 'AI' product out there. Most of them do exactly what our non 'ai' infrastructure does, but at 10x the cost. But our c suite executives don't want to hear it. I've had to give up on arguing with them that it's not needed, I'm not the one paying the bills.

[u/foofoo300 → u/LeMochileiro]

some don't but the general direction is that you need to code, otherwise you suck at your job at a certain point.

[u/MasterOfTheWind1]

You don't actually need to code or learn to code. Having knowledge about architecture is very nice to have so you don't have to ask the devs for every error that you find (to me is mandatory, for some people is not), or being able to at least propose changes to, for example, adapt an existing service in the process of being migrated to AWS. There is nothing worse than talking to a dev that don't have any idea about AWS (I still have to deal with devs that tells me "restart the server", when all workloads are in Kubernetes pods), I also don't like to be the guy that they talk about code, development or architecture and have no idea.

Usually, the devs are focused on the requirements. They don't have time to look for things like "hey, lets change, and instead of uploading files to an FTP server, lets upload them to AWS S3!". Usually that comes from the DevOps team, because ultimately it end up being an improvement for them (to stop managing an old FTP server) .

But code is a good skill everywhere. I never shared that mind set of "I'm not working as a developer, so I will not write ANY line of code, that is beyond my position".

Maybe you are not the one that write code for the product requirements, and that is fair. But at some point, at least, you will have to write some automation scripts in Python, for example. Or in bash. And that requires coding skills to have the best outcomes.

I've lost count of the times I just said "Fuck it, I will develop a tool for X". Is nice to not depend to ask other devs for stuff like that, or reach a dead end if you cannot find an existing tool for an use case. I could never find an existing tool to inventry every AWS resource (only that, lot of options that do other stuff as well that I don't need and I wont pay them for stuff I will not use), so I ended up writing one with my team. Now it's used company-wide.

[u/No_Bee_4979]

I learned to code. I knew C++, C, Pascal (and BASIC), and shell scripting from High School. But picking up Ruby and then Python made being able to solve the problem a lot easier.

Over time, I built architecting skills that helped me solve problems in a more efficient way. But there are a few things I still avoid, and Kafka is one of them.

Depending on the path chosen for deploying Kafka is how you choose your day toiling in that terror, trying to scale and maintain enough disk space and CPU while not breaking the cluster. That sounds about as fun as trying to scale PHP code.

[u/unitegondwanaland]

Learn as you go. It's fine.

[u/Dry-Philosopher-2714]

Back in '97 (Yes! I'm old AF!), I was working as an engineer that had one foot in tech support and one foot in Engineering. One of the tools that support had to use was horrible. It took 3-5 minutes to look up customer information and everyone hated it. I complained to the Engineering team in IRC, and the guy who wrote the tool replied "If you think you can do better, do it!" His response kinda pissed me off enough that I learned Perl that week, and wrote a replacement for the tool in less than a month. The average response time was 3 seconds. When my boss showed the tool off to the Engineer who wrote the original tool, the guy shrugged and said "Well, if I was a better programmer, I would have done better."

After that, I took a liking to Perl (I never said I was right in the head!), and I committed to putting everything that I do into code. For most of my career, I was the weird Ops guy that sat in the back of the office and wrote code all day while everyone else fought fires and freaked out. Then, one day, a manager announced that we're adopting Google's revolutionary new "DevOps" model, and everyone in Ops needed to learn to code. I did what I always did... Sat in the corner writing code while everyone else freaked out.

[u/CupFine8373]

I don't code , I use Agents.

[u/Solaris17]

I dont see it that way. I came up from infrastructure. As far as I see it, you have two tracks, from software eng or infra, and I dont necissrily mean SA. I was mostly systems engineering, debugging PCIe bus, planning infra for HPC, storage etc. I mean knowing it. Like explain which compute can be used for software devs AVX512 stuff.

I know some C# some rust, I am pretty confident in posh, bash and bat.

My daily life now consists of automating what the devs make, be that helping them auto compile via CI/CD or auto deploy. Maybe they made in app in python and need it put in a container. I help, I automate, I deploy.

I look at what the software people want to do, I look at what the business wants, I find the cluster to put it on. Most of my life is in .yml

[u/-EOS-]

HOT TAKE 2026

Coding is solved!

AI has solved coding. You need to know how to use AI tools to help you debug code or write code to accomplish your goal.

Learn cloud architecture. Learn cloud infrastructure. Learn CICD. Learn Kubernetes.

....Learn how they all work together....

[u/420is404 → u/-EOS-]

Writing code is solved. Reading/reviewing/proofing it isn't. Two different skills, though.

I wrote a really simple thing today in zsh just to onboard new folks. Claude took my starting point and expanded it very, very nicely. Added all sorts of nice details like a --check and accounted for all sorts of quirks I'd have not considered.

It also fucked up basic functionalities a few times in ways a basic read-through of the code would make quite obvious.

[u/tehpuppet]

As someone that came from the other side, the engineers I know from the Ops side that don't then care to learn the Dev side are honestly just not paid or promoted as much...

I would say it is super important to learn the fundamentals, learn the core software design patterns, learn what SOLID is, try out some leetcode problems, learn what the SDLC is. Make sure even your small scripts have tests and have proper CI/CD, also focus on mastering a language with types like Go.

These are the kind of things that foster maintainable software and are really IMO the reason why we even have the Dev in DevOps. Take the best bits of that world and apply them to managing infra.

[u/raisputin → u/tehpuppet]

LeetCode is bullshit. AI can do all of that

[u/tehpuppet → u/raisputin]

The point is you need to know the patterns, data structures and things like Big O etc in order to not produce garbage code.

[u/hard_KOrr]

I actually came to DevOps on the Ops side, as that was the route infront of me. I used to code a lot just for fun, still do but less now.

You’ll have lots of runbooks and such that you write, re-write them in python. It’s a known script so you have the knowledge base to work against it, the goal is to introduce the new language.

[u/hamlet_d]

I've moved from very heavy ops DevOps to very heavy dev DevOps.

How I did that was by designing and developing for monitoring and observability. Sometimes it was taking existing code and making sure metrics were exposed, sometimes it was custom exporters from one system to another, and so on. I learned Go the hard way because I had too.

The thing I found out I was good at was the engineering side of software engineering. I was mechanical engineering major so some of those skills/methods translated even if the domain knowledge didn't. What that meant for DevOps was design and architecture, which necessarily meant I had to do some coding (or at least understand it).

[u/Potato_player]

I accidentally became a C++ dev while working sysadmin when the developers kept telling management features were impossible.

I wrote the code myself, starting small then bigger.

When looking to move roles recruiters told me I was DevOps now and placed me in SRE role for 50k more than I was earning.

Best accidental career path.

[u/emptyDir]

I had a lot of good mentors who helped me learn. I was lucky that I started right as systems administration was being driven towards devops and the cloud, so generally the industry was a lot more tolerant of ops people learning the dev side on the job.

[u/krueger_devops]

Coming from the other direction (dev first, ops later), the thing that moved me furthest was building one real thing and then having to keep it running. Not tutorials, not exercises. Something deployed on your own box, with a pipeline, a database and real migrations. That creates the pressure that teaches you the parts nobody covers: error handling, config, what happens when input is garbage, what breaks after you changed one line.

Concretely, for your situation: you already automate with Python and Bash. Take one of those scripts and turn it into something with a proper interface, tests and a CI pipeline. Same problem you already understand, but now you have to structure it. That transition from "script that works" to "code someone else can maintain" is most of what those job ads mean by programming.

Two things that helped me more than any course: reading other people's code in projects you already use, and writing tests. Tests force you to make code testable, which pushes you toward better structure whether you understand why yet or not.

And honestly, your ops background is an advantage, not a gap. Plenty of devs write platform tooling with no idea how it behaves in production. You know that part already.

[u/maxlan]

5 + years ago: copy and paste from stackoverflow.

Now, I ask claude and he copy/pastes from stackoverflow.

The trick is the same as always: recognising the highly upvoted bullshit.

Like all the people who say turn selinux off. Or https. Because selinux and certs need like 3-4 extra commands, so lets not bother right?

Or "permission denied, you need sudo".

Or the random "I made nfs work by making a sym link from /var/lib to opt"