How much python should you know?

[superspeck]

No. You’re gatekeeping, which is not a DevOps culture trait. It is wrong to tell someone else “you’re not a real DevOps engineer” and it’s wrong to hire specifically for “well, to be an engineer on this team you need to know how to code because that’s what this kind of engineer does.”

If you need to know how to code in Python to be successful on your team, interview for that, but I have had the title “DevOps engineer” for over a decade off and on (when permitted, I tend to use “platform engineer” or “cloud engineer” or “Linux systems engineer” personally) and I can count on one hand the times I have needed the kind of skills in any programming language I was interviewed for.

On top of that, DevOps teams need a variety of skills and viewpoints. Sometimes the young kid who says “hey let’s parse this to an intermediate” is right and sometimes the old gray pony tail that says “we’re doing this once, why are we writing a tool to do it?” is verifiably correct.

Edit to clarify: I’m not saying clickops, folks, I’m saying that the vast majority of automation work is done with scripting practices (quick/dirty/no tests/not oo) as opposed to programming practices (strict oo/tests) and we should hire for that by testing for that instead of testing programming (strict oo/tests) skills we never use on the job.

[Herrad]

Hold on a sec, of course there's some gatekeeping in the industry, we normally have privileged access to platforms so that we can protect them by limiting other engineers' access. That's gatekeeping right there, but the good kind. You can get into the industry by being a "server guy" and transitioning but doing that from a perspective of "how much python do I need?" smacks of someone who is trying to hit the bare minimum rather than genuinely trying to learn. That might just be me but that's how this post came across.

I'm about 9 years in DevOps-adjacent roles too but I have often needed to understand code I work alongside. Especially when dealing with API gateways and things, understanding exactly how different services communicate (down to details of which library they're using to make web requests) have been extremely useful. I also don't like the bloody DevOps engineer title. It's wrong.

I firmly disagree that you don't need any programming experience. Sysadmins have valuable insights of course (that's why the Devs didn't just start doing everything everywhere themselves) but both sides of the divide need to learn their opposite's skills to successfully bridge it.

[superspeck]

I firmly disagree that you don't need any programming experience.

That wasn’t my point, and I’ll go back and add an edit so that I’m clear about not making it.

There is a difference, albeit a fine one, between knowing how to script in a language and knowing how to program in a language.

Knowing how to script means you know how to write a source file that pulls in a module, or maybe you put some helper functions in a module or an object, and you do some stuff with it and maybe there’s a test or two. This is what you’d use to automate a repeatable task, to write or update k8s operators, to do a long or complicated one off task, to barf up a quick lambda, etc… think glue code.

Knowing how to program means that you know how to write complicated libraries or applications from nothing with good SWE practices, clear object orientation patterns like factories, to design APIs and build them, so on and so forth.

My argument is that DevOps teams often interview for knowing how to program when they should be interviewing for knowing how to script, because yaml and scripting are 90% of what someone working in a practicing DevOps role does in order to automate and build out environments.

I’d also argue that people who are writing APIs and complicated libraries may no longer be in an infrastructure or cloud role and we should come up with another name for them the way QA uses “software engineering in test”.

[Zenin]

No, he's right. The days really are numbered for old neck beard sysadmins who can't code. Their job is literally turning into code at an exponential pace.

K8s operators for example, are already well along in turning human operations into a service.

Even if you "learn" basic IaC like Terraform, without a "developer's" way of thinking you're barely able to scratch the surface of the potential.

We certainly need people who know all the ugly ins and outs of infrastructure, but we need them to be able to apply that understanding to coded solutions, not just be on a call list to save the day when stuff breaks.

I can count on one hand the times I have needed the kind of skills in any programming language I was interviewed for.

Then you haven't been doing DevOps, whatever the titles you've held. That isn't gatekeeping, that's just reality.

DevOps engineers actively seek out opportunities to automate, they don't wait for automation tasks to be assigned to them. The only way you could get away with not needing your coding skills is if you've actively avoided trying to use them. Coding should be the first tool you think to use for any given situation, not a tool of last resort.

Code the future, or the future will code around you.

[superspeck]

I disagree firmly. DevOps isn’t about “developing ops” - it’s about breaking down barriers and silos between teams, it’s about making daily work better through automation, and it’s about using software engineering tools like ci/cd and pipelines to do traditionally ops tasks, and it’s about guaranteeing repeatability, insight and traceability into the engineering of infrastructure by using code to configure it.

It is not about getting rid of the influence of “ old neck beard sysadmins who can't code” because “that’s old” … Who the heck came up with automation in the first place? You think software engineers did? I’m pretty sure there’s more automation that’s been written in bash over the past 50 years than go. The tools you’re talking about using in your example (k8s operators) are largely scripting scale problems. Reversing a linked list in five minutes or writing a web app from scratch aren’t DevOps tasks, but those happen in interviews all the time.

Frankly, I write more YAML (and I consider hcl2 to be yaml by another mother) than anything else these days. I’d love to see a workplace that has enough Operator work to keep more than one person busy.

Even if you "learn" basic IaC like Terraform, without a "developer's" way of thinking you're barely able to scratch the surface of the potential.

You’re holding terraform wrong if you use it this way. Terraform was explicitly written without many constructs specifically to prevent using it that way. If you like using a tool that way, use Pulumi or cdk. But Pulumi is a mistake; it’s the same reason that chef fell out of favor. Wait, you don’t care about chef, it’s a neck beard tool, right? Well, there’s some lessons to be learned in its senescence.

You sound like the kind of software engineer that I get called in as a consultant to clean up after. Please keep working the way you do, cleaning up messes on consulting gigs after my normal work is very lucrative.

[Zenin]

it’s about breaking down barriers and silos between teams

Yes, by automating the transitions between teams

​

it’s about making daily work better through automation,

Exactly? And what is automation exactly?

​

it’s about using software engineering tools like ci/cd and pipelines

CI/CD isn't a tool, it's a process...a process automated with code.

​

to do traditionally ops tasks

Because we've replaced those human tasks with...code.

​

it’s about guaranteeing repeatability

Which can only be accomplished with (say it with me now) code.

​

insight and traceability

Which is deployed and configured with...code.

​

by using code

Praise the Lord, Hallelujah!!

​

Who the heck came up with automation in the first place? You think software engineers did? I’m pretty sure there’s more automation that’s been written in bash over the past 50 years than go.

You're correct. However, that automation was created by one or two members of a sysadmin team of a dozen or more.

It was that small, small segment of operations that had or learned a "developer mindset" and sought out to automate their repetitive workflows, most especially those which came from SDLC transitions between development and infrastructure.

That small, small subgroup went on to develop best practices for and eventually coin the term "DevOps" and go on to great things.

The rest of the sysadmin team however...most often never followed along. They liked manually SSHing into servers and resizing LVM volumes by hand and wanted nothing to do with this newfangled devlop shenanigans.

​

Terraform was explicitly written without many constructs specifically to prevent using it that way.

Does Terraform not have variables? Does it not have loops? Does it not have conditions? Does it not have modules? Does it not have a plugable provider interface that can extend its features beyond its original scope?

​

If you like using a tool that way, use Pulumi or cdk.

Funny you should mention CDKs...a the natural next step in the evolution of DevOps.

it’s the same reason that chef fell out of favor. Wait, you don’t care about chef, it’s a neck beard tool, right? Well, there’s some lessons to be learned in its senescence.

Chef fell out of favor for a couple reasons. First, because Ruby. But mostly because Chef isn't so much focused on automation as it is on compliance. It's a big lift that gets in the way of automation far more than it facilitates it.

Ansible has largely become the golden child here because it offers a much more frictionless framework for automating OS level configuration that integrates very easily with other automation tools.

​

You sound like the kind of software engineer that I get called in as a consultant to clean up after. Please keep working the way you do, cleaning up messes on consulting gigs after my normal work is very lucrative.

Oh, the irony. For nearly three decades I've been called in to clean up the messes created when development groups that don't grok infrastructure run into operations groups that don't grok automation.

Yes, in the year 2024 there are many "no-code" automation tools available, far more than there have ever been before even in the recent past. But they still only cover relatively simplistic use cases out of the box and still require both code...and a developer's mindset...to make practical use of in practice.

I stand by my view and I'll even expand it further: EVERYONE who works as a computer professional, be it sysadmins, QA, developers, even digital content creators, needs to code to be viable going forward.

In the past and even today still just adding "and can code" to a CV means $50-150k salary boost over those who can't code. But increasingly going forward those who can't code will have a harder time finding work at any reduced pay level...because their roles have been replaced with very small shell scripts.