The ability to write code is a huge differentiator for every job role in an enterprise Linux environment. As an Operations and DevOps manager, I was constantly challenged to improve my team’s programming skills, and the team genuinely wanted to be more proficient.

But how?

Structured training is a standard answer: take a course! Our company, like many, invested enormously in learning resources. I’d sit with an engineer one-on-one and we’d ponder the online portal together, puzzling out the most appropriate Python learning path.

There are two issues, however. Problem one: classroom material is almost immediately forgotten, if not directly applied. Problem two: I’d lose visibility of progress for days, weeks, or even months. I’d find out too late the material was inappropriate or too advanced.

I want to share three supplemental approaches I found effective in helping engineers get comfortable with programming while becoming immediately productive. Each is suited to a different baseline skill-set.

New hires: teach the framework, first

No, or very little, programming experience? Don’t ask the engineer to write code; instead, write documentation. This sounds contradictory, I realize. But this is the key: the engineer is to treat what he or she writes exactly like code. Your team’s development practices are to be followed scrupulously, regardless of content. And if your shop isn’t already handling technical documentation like code, please start!

Really -- it's not basic language constructs and procedures that are a struggle for the inexperienced -- it’s everything else. Immediately more important than writing code are the concepts of a repository and mechanics of Git; continuous integration, continuous delivery (CI/CD) pipelines, installing and configuring an integrated development environment (IDE), etc.

In my team, I challenged very new programmers to write “runbooks” – a set of written procedures used for incident response by Level I support and sysadmins. And I expected an iterative cycle; the runbooks would be properly merged in our repository, and be continually updated and revised, reinforcing this practical learning. You “get” Git by using it over and over.

Asking new programmers to write documentation helps in these three ways:

1. The employee develops a hands-on understanding of version control and other tools fundamental to best practices.

2. The output is immediately productive, and appreciated by peers.

3. It’s an easy transition to the next logical step, which IS programming: replacing the manual actions with automation.

More experienced: modernize legacy code

Many engineers may have some programming skills, great intentions, but struggle to deliver a working solution. They are assigned an issue that’s ultimately too complex and get frustrated and anxious. Or at least YOU get frustrated and anxious at the growing technical debt!

A practical solution? I guarantee your organization has a non-zero number of ancient shell scripts or code written in a legacy language. Maybe there’s a Windows VM lurking because no one’s taken the time to get PowerShell working on a Linux system.

You know what’s fun with a PagerDuty call-out at 02:30? Nothing. But especially annoying is trying to understand some regex parsing routine written years ago in awk that broke when a UI change was pushed off-hours.

This is a perfect opportunity to have these shell scripts re-written in your organization’s language of choice and convention:  a “cross-language refactoring,” approach.

There are big advantages to refactoring shell scripts: first, as you have (presumably) working code, business isn’t impacted waiting for delivery -- the new code is written in parallel. Second, the engineer can use the existing script(s) as a template. Finally, your repository is modernized and automation is written in the proper programming language: arguably not the shell!

Solid skills: extend the boundaries

Senior team members may be bored and looking for additional projects, or want to learn a more current programming language. Perhaps your DevOps pipelines, or sysadmin procedures are relatively mature, and much of the job is simple maintenance and updates.

I promise there is SOME critical metric, whatever software your team uses for application performance monitoring (APM) that isn’t easily visible. And your boss, and her boss, and maybe an executive would like to see it.

Consider challenging your top engineers to write a web-based application or dashboard that surfaces this data. I found this to be a great approach for two reasons. First (admittedly more a human engineering hack), the potential for name recognition up the management chain is a powerful incentive. Second, the developer must address an end-to-end solution across different application tiers and technologies. It’s also a great opportunity for mentorship, as focus is scoped to a specific challenge as opposed to an open-ended, vague request.

As an example, one of our executives wanted regular updates on customer on-boarding. Collecting the metrics manually was tedious. A sysadmin attacked the challenge by writing scripts to query both database records and unstructured data on disk at regular intervals. The output was formatted, and automatically posted using Slack’s native webhooks every 6 hours to a management channel.

In summary, I don’t want to deemphasize the importance of classroom education when learning to program. But for new programmers, immediate hands-on experience with supporting tools is fundamental for future growth and delivering documentation is a great way to learn the tools and processes. For the more experienced, consider refactoring old code to comply with your current practices. Finally, challenge the high achievers with writing a web application, or otherwise publishing critical data to the larger team.