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.