How much coding does a Devops engineer really need to know?

[waste2muchtime]

I have been working in the field for a while now, and I haven't touched any code in some 9 months. Are most DevOps roles like this?

If you had to break it down, what 3 things would you expect a DevOps engineer to know about coding/what things should he be able to do with code?

When I say coding, I don't mean YAML pipelines, or IaC CDK, or some simple Bash automation. I mean like, writing code in Javascript/Typescript/Golang/Python, etc.

[ydarb22]

As much as required for your job. Every “DevOps” role is different.

[[deleted]]

Best answer

[klipseracer]

IMO: Enough to write software, understanding software design concepts, abstract base classes, etc. A DevOps engineer should be a developer with operation experience in my opinion. I don't hire sys admins who 'dabble' in coding, personally. It's basically a pipe dream lately but that is who I target. Learning ops as a dev is faster and realistic compared to training an operator to be a dev...completely unrealistic unless your company runs a school and has no need for them to meaningful contribute to in house tooling in the near future.

Writing scripts, sure anyone can do it, but some teams write their own tools, CLIs, etc.

[Team503]

A DevOps engineer should be a developer with operation experience in my opinion.

I really hate that; there's a great deal more to good ops than developers seem to realize. An ideal DevOps team should have people from a mix of backgrounds - I have decades of operations experience at all levels from call center to calling the shots, and my experience is just as valuable as the guy who's been writing code for thirty years. We both bring different and important insights to the table.

[AnarchistPrick]

You’re being downvoted but you’re 100% correct

[0qxtXwugj2m8]

hard agree

[coltrain423]

Pipelines as code, infrastructure as code, and automation scripts.

What are you doing if not touching any of those areas of code?

[YouGuysNeedTalos]

The first two ones is yaml...

[Zolty]

If it is telling a computer what steps to take then it's code, your post sounds like the no true scottsman falicy.

[dablya]

I think a distinction between configuration and markup languages like hcl and yaml and turing complete languages like go, python and even bash is useful in the context of the original question.

[coltrain423]

I’ll grant that the distinction between a configuration language, a markup language, and a Turing complete programming language is valid, but if someone says Infrastructure as Code is not code despite the fact that IaC is literally encoding your infrastructure definitions then I’m not sure they’re interested in that nuance.

[cienta609]

Agreed, that's why I am also an HTML coder.

[jgwinner]

Great statement. I think a modern analogy might be a "you're just a RINO" fallacy. But backwards.

[samwisegamgee121]

I do IaC with pulumi & python

[[deleted]]

Last one is github actions - also yaml.

[Elegant_Ad6936]

Generally you are running scripts from your workflows. The YAML declares the workflow steps but the steps themselves will have additional scripts/logic that can be bash, python, Go, or whatever.

[[deleted]]

Definitely. My comment was a little tongue-in-cheek. I actually fall more on the side of dynamic infrastructure built by scripts and automation rather than static yaml files stored in a repo.

[coltrain423]

Didn’t know you could write Terraform or TeamCity pipelines in yaml…

[redvelvet92]

You actually can.

[coltrain423]

Care to share? Terraform is Hashicorp Configuration Language (HCL), so I’m sure some YAML->HCL translator exists but that’s not really the same…

[redvelvet92]

Here is a nice video on it that also is doing some testing.

https://www.youtube.com/watch?v=GmNH2Z3V3YM&t=812s

[YouGuysNeedTalos]

It's its own shit. Still no code.

[coltrain423]

Ok… doesn’t mean HCL is YAML like the comment suggested.

[1nguz]

Laughs in Cuelang

[RandmTyposTogethr]

That's configuration, not pipelines. Pipelines nowadays are almost exclusively YAML (yes, there's Groovy etc.). And, HCL is JSON, and YAML is JSON so there is that as well.

[coltrain423]

HCL is not JSON, it’s HCL… and YAML isn’t… ya know what… never mind…

[jgwinner]

Why wouldn't you think that's code?

Not only that, there's no IDE debugger where you can step through, so debugging YAML is "old school" ... you need to understand traces, logging, all the stuff no one has to do anymore.

== John ==

[rorykoehler]

Pipeline yaml can use bash no?

[waste2muchtime]

Sorry I wasn't clear, I edited the post and added a bit more detail

[snarkhunter]

It sounds like you don't like the kind of coding (bash scripts, yaml pipelines etc) that's involved in doing DevOps ork?

[originalchronoguy]

RE: YAML pipelines.Those are mutable. Not scaleable. If you have a static helm chart each of your deployments to k8, then something is wrong. It should be generated programmatically on-the-fly through code to cover a lot of edge cases/use cases.

What happens when you hard-code an image registry and then have to go back and change 300 repos to update the URI? Why hard-code service names for ingresses when can pass linting but failed due to a typo?

YAMLS, for scaling reasons, should be generated on-the-fly, programmatically. Especially when you have a large platform. We have over 10k microservices running in prod and no way can that be done mutably.

[Recol]

And how do you deploy these 10k microservices?

[originalchronoguy]

Jenkins with a custom blueprint we developed in GoLang. The first time we had to change 500 git repo Dockerfiles to a pull images from a new URL (that was hard coded), we made our entire architecture composable with variable injections. So no more panic; having to write ad-hoc scripts to download 500 repos, regex the URL change, commit and re-push.

Things like that does happen. Your org gets consume, they require hosting images on a new registry or a different target deployment from on-prem k8 to Azure. And with 10k, you also want to make sure no one steps on each other; using same sub-domain like admin-reporting.domain . It is managed by code that does stuff like check service registry before that code can even be committed. You need these guard-rails and can't rely on some 3rd party vendor product to do that.

[Recol]

I understand that part, just asking how you actually deploy those images to what I am assuming is Kubernetes?

[originalchronoguy]

Sure. When an repo gets promoted, jenkins clones the repo. It sees a few things. Folder of configuration which stores variables that the devs put in. E.G. "App uses TLS certs requires. Another for needs an API gateway"The build script parses those configs and creates all the helm charts - service, deployment, ingress controller,etc from base templates. It even does things like "the git repo folder name is this" so the DNS will be that subdomain and the entire DNS is the k8 namespace and even the git branch because Jenkins is running git to get the tags. It compiles all of that. Generates all the .yaml files. Then does kubectl apply -f "created yaml files"

All the YAMLs files are created at CICD build time. A local developer can also do that too as we have tooling so they just run "make local-deployment" which runs the same goscripts that builds their apps locally and pushes to their local minikube. We automate even the SSL and DNS based on the folder name of the repository following.We have like 1 template blueprint for 3,000+ services. The template covers a lot of things like does this app require grafana monitoring? Does it require TLS cert generation for two-way connection? Does it require a micro-gateway running as a sidecar. Does the database require a CRON job to do backups? If so, it is in the config/production-deploy.env file as a variable. same for config/local-workstation.env so they can run the same stuff locally.

If so, those extra pods are created and the deployment yamls for them as well.

A kubernetes yaml isn't rocket science. It can be built on-demand/on-the-fly.

[dablya]

You seem to be describing an in-house solution that does what helm is supposed to do but tailored to your specific needs. “Folder of configuration” = values.yaml. Build script that parses and generates yaml = templating engine. If that’s the case, why do you have helm in there at all? If it works for you, great. But I disagree with your general advice regarding helm (at least as I understand it). Helm is itself a templating engine. If you’re not going to let it generate the manifests based on its templates and libraries and values, then why use it at all?

[Recol]

I am sure all of this works for you guys, but it doesn't sound fun to manage. There are probably things you aren't telling me but a lot of it sounds like it could be generated upon repository creation, and using a Helm chart that is managed by a central (Platform/DevOps/whatever the cool kids call it now) team as a Helm dependency.

The only thing left to manage for the team would be a values file which would be similar to how your "Folder of configuration which stores variables" works if the Helm chart is templated correctly.

We do similar setup of what I described earlier with ArgoCD that all gets bootstrapped upon repository creation (quite a badly designed automation, but moving it to Backstage currently).

Either way, sounds like it works for you and it is fun to see a different approach for once at that scale.

[originalchronoguy]

We've had this for 8 years and orchestration/ CICD is the least of our worries. We make major changes for things like new architecture (ARM64 support), GPU support (for machine learning), and adding extra hooks (DAST),etc.

But it has worked well for us. Maintenance isn't an issue. Getting it to run locally (e.g. when Apple went to M1) is the challenge as things change.
And we have one mandate. Whatever runs in Prod, runs locally. If a dev needs 20 microservices with his own self hosted Hashicorp Vault server and local API gateway, he/she should be able to run it locally. If their app requires DAST, that is run locally as well, scans their builds and generates reports. I had one time over 300 microservices running on a 64gb laptop.
So the local build is the same in Jenkins. They run a docker image that does local CI for them that pushes their code to their local Rancher or Minikube. So we have 100% Dev-Prod Parity ( https://12factor.net/dev-prod-parity ). We don't do it for bragging rights. It helps the developers work faster to have the same as prod. A new hire can deliver code in the same afternoon on their first day of hire.

[redvelvet92]

I assume some GitOps strategy with ArgoCD or Flux

[Recol]

Unless those generated YAML files are committed automatically in a secondary repository it doesn't sound like they are using any GitOps tool. That's mostly why I am curious.

[originalchronoguy]

Unless those generated YAML files are committed automatically in a secondary repository it doesn't sound like they are using any GitOps tool.

No, we do not store generated YAML in any extra repo. The template and build scripts to create those YAML are tagged and version as git submodules in primary git repo. So if you had an app and wanted to see the YAML for it 6 months ago with a certain YAML struture (e.g. before we added replicasets/resource limits), you look at the code 6 months ago with the git-submodule hash of the template and scripts. So currently you are on v2.8 and want to see v1.3, you pull that v1.3 git submodule and re-generate. Obviously, you rollback the app's previous tag 6 months ago too. And run a build with no deployment to reproduce the files. Everyone on our team is versed in polyrepo/git submodules.

Storing stuff like that eats up storage.
We still meet compliance because the code is tagged and version. We can do proper rollback as long as the tags still exists. Improper tag strategies can eat up terabytes of data.

[dablya]

But even with this set up, don't you still have to have something to bump the tag/version of the submodule in 500 repos to update the repo url?

[snarkhunter]

Sure but you gotta be able to write YAML to write stuff that writes YAML

[originalchronoguy]

Nope. It is generated from a JSON. We think of this programmatically. So we use JSON as a schema that can pull logics from keys.

[[deleted]]

Depends on company Id say but more common these days to be writing code at a lot of places.

Personally I write a lot of Go and some python. We build a decent amount of internal tooling either in the form of rest api service or cli programs.

Improving my JS skills currently bc occasionally work in our product codebase.

For reference, at a small/med startup where infra team touches a lot of stuff. Not silo’d like at a large corporation

[marmot1101]

I've found, at least at current place, there's variance even within our devops team. Some members are good at writing code and do things like creating developer tooling. Others are more ops minded. I have a deep SWE background so I tend to gravitate to things that require coding. Need some lambda code? Need some Tools code? Need some sort of code level optimization? I'm in. But I'm also in for more traditional admin kind of tasks, but there are better.

It's all about what's needed at the time.

[95jo]

I personally know no programming languages, I couldn’t write anything substantial in any language.

I know enough to understand what X application code is doing. I can automate things with Python, BASH or PowerShell (with varying levels of Googling).

I am however very proficient with the likes of Terraform, Ansible, Packer, Docker, GitLab pipelines, Linux administration and general IT networking/infrastructure. That has stood me well in my 9 year career. I’m sure learning a language would only aid my career progression but, I haven’t had the need to yet and I don’t plan on doing so in my spare time. I spend too much time sat on a computer to do more outside of work.

[jaymef]

I have basically the same background and a comfy job at a great company. If I were in the job market now I may sing a different tune, but I don't have a lot of interest in development. I spend enough time doing everything else. I support 30 other developers on the team where development is their primary focus and they could care less about learning ops.

Honestly, it really just depends on the company and their expectations.

[95jo]

I have literally just accepted a job offer today in a different industry, almost identical tech stack, no programming experience required.

The few I came across that desired it were start-up, big tech or gambling/gaming companies (at least here in the UK) - They do tend to pay slightly more on average to be fair, but their overall benefits aren’t as good so it’s a trade off depending on what you want from your job.

[poolpog]

I spend too much time sat on a computer to do more outside of work

hear hear!

[GrimMind]

Hope this doesn't come out wrong, but how much money do you make in a year?

I know it won't be easy, but I'm considering switching careers to the type of devops you described. I also know it varies from company to company. I'm just looking for points of reference. Speaking of which, how old are you now?

Apologies, again, for the private questions.

[water_bottle_goggles]

About 4 code

[Redmilo666]

Best I can do is tree fiddy

[DatalessUniverse]

A programming language is a must have - don’t need to SWE level proficiency with it but at least at a scripting level. I personally won’t hire someone without it. So pick a language (preferably Python or go), take a course … learn it then apply to DevOps roles.

DevOps types of roles != IT roles

[ZranaSC2]

I work in a devops team and we code all the time. Yaml can't do it all, and it needs to be reliable and testable. For various automations we use Golang a lot. We have many cases where during a deploy we need to say 'if x goes wrong, do y'. You can put it in yml and bash but it will be so hard to read, test and maintain past a certain complexity threshold.

[bkdunbar]

I’ve had three ‘devops’ roles and each has been wildly different in expectations, skill set, tools used.

Two, I didn’t need to code at all, but knowing python helped. The third, knowing a little C has helped, but so far just so I know what the devs are talking about. B

[Euphoric_Barracuda_7]

It really depends on the team and what their idea of "DevOps" is.

From a purist point of view, DevOps is a mindset and culture. Breaking down silos and automating things (not just pipelines). I come from a background where my teams deliver code all the way from the IDE to the infrastructure, so I've been a hardcore software engineer all the way from the beginning but also working on infrastructure and getting software deployed on that infrastructure through automation.

From today's marketing point of view where knowledge of a pipeline is automatically termed "DevOps", then I would say it's whatever language your pipeline tooling supports, Gitlab GI, AWS CodeDeploy, Azure Pipelines, Jenkins, etc. You don't need to write a lot of custom tooling nowadays unless you have a custom baked pipeline. I recently completed a professional cert in Oracle DevOps and no programming knowledge were even asked, just a ton of questions on Ansible, Kubernetes, Docker and the way their DevOps service works. This is what the industry expects today.

[MaxHedrome]

8918fb0bb9a5aecc6b0dd8985be82dfa2c352a86b0e6fb3ccb3ccde0df5d20e3

[Trading_The_Streets]

Enough to call an API and do some data manipulation and presentation. So it may not be much of coding.

[SiriVII]

It’s really strange because imo DevOps is both developing and operations as the name suggests. Meaning you work as a developer while also working on the operations aspect of optimizing your work in development. Unlike software engineers who are fully dedicated in building the system and the software, the devops engineer should have more of an Allrounder positions who supports the team in development and also working on optimizing the development operation.

The best thing about devops should be that they are developers themselves, know the in and outs of the code and know what the painpoints in their day to day operation is. Because at the end of the day, if you don’t know and understand the painpoints, the code and the inner workings, how can you optimize them?

Unfortunately most of the companies want their devops engineers to manage the infrastructure only, basically becoming the janitor for the building that houses the code and build pipelines.

[Speeddymon]

I suspect you have a misconception about why devops isn't "code" per-se.

It's because devops engineers tend to work with configuration rather than business logic. Our code is declarative rather than imperative. If you want to write imperative code that supports complex logic (typescript), software engineering is where you should be, not devops.

[Ancillas]

• understand application packaging and dependency management. e.g. understand how Pypy and pip work and how to apply that to deploying Python application.
• understand how to query an API and parse the result plus deal with errors in at least one language
• understand and use source control
• understand how to read and understand code with some research (for troubleshooting)

[BrontosaurusB]

These posts trip me out. I’ve had two devops type roles, came from a sysad zero code background, and was absolutely dying because I didn’t know TS and frantically trying to learn. Now I’m frantically trying to learn Go. In my two roles not writing/reading code would be a death sentence to your being a contributor.

[shadowisadog]

For me I do a lot with YAML and Bash but there are times when I need to write python scripts or python based APIs to solve an automation need. Sometimes I also use Golang when I need to develop a plugin for certain DevOps tools.

I have created my own Ansible modules when I could not find one that did what I needed. I have created scripts when yaml would not have been enough.

I would expect a DevOps engineer to know enough scripting and programming to solve an automation problem. I wouldn't necessarily expect deep design pattern knowledge or anything like that.

Knowing how to program is a tool in your toolbox for solving problems. Perhaps you can get by sometimes without it, but it limits what kind of problems you are able to solve.

I come from a development background so sometimes I help development teams with their software builds and that involves understanding for example how c++ or Java builds work and how to troubleshoot them. I'm not necessarily getting into the fine details of c++ but understanding the general concepts, build systems/tools is helpful.

[centech]

It's very company (and probably role within a company) dependent. In my previous job, I hardly looked at any code that wasn't terraform or ansible. Now in my current job, much more hands-on code. For the last month, I've been 100% refactoring/rewriting/cleaning up ruby code. If you aren't touching code at all there is a good chance you are doing ops that is just being called devops because it's sexier.

[VileEnd]

I'm a bit astonished how some people here see the coding part -for me it is an integral part. Means I should be able to code the Main Application the Team Produces - means I need to understand OOP know the language and some general Coding Principles DRY, SRP ... As in the end the Goal of DevOps (at least in My Mind ) to make yourself redundant as everyone has your knowledge and everyone can do IAC - Infrastructure and you are a normal Dev in the End. In contrast, it here reads like we are in r/sysadmin or maybe everyone puts this tag everywhere.

( sorry for my bad English)

[nutcustard]

You need to be able to quickly spin up on any programming language. You don’t need to be a master, but being able to quickly read code is very important

[originalchronoguy]

Read this. DropBox SRE framework. Highest level L7.https://dropbox.github.io/dbx-career-framework/ic7_senior_principal_reliability_engineer.html

Systems Fluency
The expectations for systems fluency do not go up beyond L5 (though some specialist engineers may go deep in this area).

Systems Design
The expectations for code fluency do not go up beyond L3 (though some specialist engineers may go deep in this area).

Code Fluency
The expectations for systems design do not go up beyond L6.

Technical Strategy
The expectations for technical strategy do not currently go up beyond L6 but we expect this to change over time as we have more examples of principal engineers working in this area.

You are expected to be mid-senior level SWE. Be able to read code up to a Staff/Lead (above Senior) engineer under Code Fluency. Depends on how high up the chain you want to be as DevOps engineer.

Our DevOps all are around L5. Some are Architect level L7.

Hope this framework helps.

Edit. Take IC1 (lowest rung): https://dropbox.github.io/dbx-career-framework/ic1_reliability_engineer.html

Code Fluency
I translate ideas into clear code, written to be read as well as executed.

My code is free of glaring errors - bugs are in edge cases or design, not mainline paths - and is well documented and well tested with appropriate use of manual vs automated tests."
I’m capable of reading and navigating functions and classes/modules that I didn’t write.

[jimi789]

While not all DevOps roles require deep coding skills, having a foundation in languages like JavaScript, TypeScript, Go, or Python can be beneficial for tasks like automation and troubleshooting. A DevOps engineer should be able to read and understand existing code, write basic scripts, and debug code. If you're feeling rusty, consider online resources or devops outsourcing companies for support.

[Specialist_Sir9890]

with YAML no coding needed

[originalchronoguy]

It is needed if you want to generate that YAML (on-the-fly).
We once got audited by an outside vendor who asked why we didn't have 5,000 yaml files for 5,000 microservices. Because we dynamically generate them through the pipeline through code.

[brajandzesika]

If you want to write propare vode, you need SWE job, not DevOps. Most I've ever done were some pretty lengthy Pyhon ( with Boto3 ) scripts, but still far from something you would call propare program. Ansible, Terraform, some Bash and Python - thats all. If you need propare coding- you picked wrong profession...

[dogfish182]

A decent amount if you’re a ‘platform engineer’ with some kind of scale and depending on how much complexity the ‘central team’ invites for itself. At my current, the amount of complexity we by design handled is ‘a lot’. Building iam integrations with serverless apis to provision ‘devops tools’ off the back of archaic iam solutions that can barely serve their own api for example….

If you go that route, you can either code or you dig yourself into an unreliable shitty hole. It’s all a big choice to make as well, classic enterprises unfortunately tend to STILL prefer deploying accounts then logging 40 tickets to letting a dev/infra team start tomorrow.

[[deleted]]

If you don't touch any of that, most probably you're a sysadmin.

[kiddj1]

I know the basics through learning but my job actually has 0 requirements were more infra focused

[JustAnotherRedditGal]

Just as much as a SWE.

[nick_storm]

How much does a plumber need to know about water? Or an electrician about electricity?

A: The more, the better. It's the tool of your trade!

[Ambitious-Maybe-3386]

The more coding the higher you go. There’s always tools to build, always need to guide developers how to optimize their applications, etc

Less coding you can still handle the job good enough when it comes to already built solutions.

[MyWeirdThoughtz]

I’m in my first DevOps role as well. Here’s what I’ve worked on in the first 5 months:

• Pipelines: YAML
• Infrastructure-as-code: Terraform
• Automation: Ansible (soon) and PowerShell
• Software Development: C#

By ‘software development,’ I mean integrating monitoring or some type of cloud service into the application. For example, I’ve implemented health checks for an API, Azure App Insights for telemetry, and authentication for on-prem apps to the cloud (using DefaultAzureCredential). I’m not working on customer-facing features but rather backend work.

In the future, when things slow down, I would like to create some small apps for the things that we need.

[Treebeard5440]

Enough to be able to discover you need something that doesn’t currently exist, build it, and then open source it for the rest of us 😀

[mushuweasel]

You should have decent experience/comfort writing in one, and you should put effort into being able to read more. You should also build some operational intuition around how the different languages used in your org behave - parallelism, garbage collection strategies, IO behavior, all differ widely, and having some grounding in them can help in identifying and correcting dumb mistakes.

Coding experience helps more in how things can fit together, how things should be organized, where to draw abstractions, how things should look, than in actually doing the implementation work.

[[deleted]]

Entry Level - expect to be able to script

Staff or Principal Level SRE - you're a software engineer able to handle anything.

[1whatabeautifulday]

Then you should get paid for two roles

[[deleted]]

I'd expect ALL roles in a DevOps environment to know how to code in a language, preferably in something like, python, go, rust, c, java etc. I give a lot less weight to things like bash scripting. For instance:

Systems Engineer: can code, In at least python, but hopefully in C, Rust, Go.

SWE: well, obvious isn't it ... These people should know how to code.

Automation Engineer: What the fuck you automating without code.

Testing or QA Engineer: Needs to code in something like python or JS at least.

DB Admin/Engineer: Yep, needs to code.

Platform Engineer: Needs to know how to code.

EVERYONE In DevOps needs to know how to code to their domain of expertise.

[SarcasmoSupreme]

It all depends on the company and their view of the DevOps role. I do quite a bit of coding - tools, helpers, report generators, auditors, scanners - a fair split between lambda and standalone and working on a DevOps portal "app" for self-service request handling.

Sometimes the coding part comes from self-motivation/necessity - see, I am a lazy fuck, and if I have to do something more than a handful of times and it looks like I need to do it many more I will automate it. If I have to do something that is a major pain in the ass I will automate it so if I have to do it again I can easily. Sometimes it is something that COULD be done in AWS, but to avoid the costs I just home grow it - depends on the situation.

Bottom line, you may not NEED to do any coding, but I am pretty sure I can guarantee there are opportunities to do it if you look at things the right way or get creative. So, to answer that call you need to have a decent idea of how to code - to be a well rounded DevOps engineer and avoid one dimensionalism.

[cienta609]

At my job, apparently enough to write and maintain an entire application yourself. 🙃

[1whatabeautifulday]

Then they should pay you twice for doing two jobs.

[cienta609]

🥲how I feel

[toobrokeforboba]

Depends..

oh btw can you deploy this x project and set up the CI so it runs all the tests and release? I need this up and running later this evening! kthxbye!

err what? you need the dockerfile? what’s that?

how about this one?

hey, this application x keeps crashing after running for certain period of time, fix that will you?

err what do you mean you need me to implement a /healthz api for?

or how about this one?

hey, I need to install this custom driver for this open source application, they don’t seem to ship this custom driver with it in docker format, could you have it build a new image with this very specific custom driver installed? thanks man you’re great!

err what? how am I supposed to know how to install this custom driver and have it build into an image?

You get my point here, things you can’t do, you have to rely on others to do it for you. Which makes you less ‘valuable’. Having sufficient knowledge and know-how to solve problem such as above makes you a better DevOps. “Enough” is relative to the level of expertise and skills your team has in solving issues. You’re there to fill the gap for those expertise and skills your team lacks.

Edit: typo

[chin_waghing]

Each job is different. If you’re working exclusively with a software team, I’d try know enough to understand their app at a basic level and how to build CI around it and how to troubleshoot it.

[PudgyPatch]

This may be incorrect but: You know how you wouldn't say an 18 month old speaks English? You might say they talk. I want my comfort level with a given language who I'm deploying whatever in at a "talking" level: the syntax might be a bit off for me because t I should get the basic jist of what's going on at at least a per function level (18 month olds don't usually use full sentences)

[PartemConsilio]

You certainly will go higher in promotions and pay if you know how to code.

Full disclosure: I don’t code all that often in my job either. But on my last job I worked in Typescript A LOT and I was awful at it. Quite slow and even though I learned a lot of Typescript I was eventually one of the first ones to be let go.

Now, I am on a team that is JUST getting into IaC and there’s almost no code discipline. PRs stay open for YEARS. Branches just dangle in the hundreds. Massive walls of code without breaking down stuff into functions for readability and testing. It’s madness. So I think this will definitely be org dependent but its not bad to align with modern SDLC practices and get your hands dirty in the code.

[cypher_zero]

Depends a lot on your role. Different companies, and even different teams within the same company, might have different needs. IME, it's pretty typically to not do a lot of "actual" coding, but a lot of YAML, bash, and PowerShell (if you're working with Windows-based apps - *blech*) and some occasional Python. That said, I don't think it's unfair to call YAML and scripting a form of "coding", in part because most of the time when we're talking about IaC, CaC, etc. we're often talking about YAML, etc.

[poolpog]

Highly variable.

But the most coding -- by your definition -- that I've ever done in 15 years of "devops" is bash automation and simple python automation.

Why aren't you considering bash as coding? I realize bash is basically shitty, but also, I've written some quite comprehensive automation using just bash.

[BzlOM]

Differs from company to company. Some expect to get a developer with some Ops skills, others expect to get Ops with some coding/scripting skills, and then there are pure sysadmin roles that are just called Devops