When I create cover letters and resumes, it is always a challenge to convey that although I don’t code in a compiled language like C#, I understand and enjoy applying serious structured coding and testing techniques to the PowerShell code I write.
I believe this is not a small distinction when looking for DevOps professionals. Many of us from the Infrastructure side of the house cut our teeth on coding by hacking together useful scripts in languages whose capabilities were Neanderthal. A good portion of time was spent working around the limitations of the language, rather than being empowered by it’s capabilities.
To be fair, not progressing to structured coding techniques is a form of leanness. When structured techniques are over-done for their own sake, they can easily result in unnecessary complexity and maintenance challenges. However, when the job at hand requires them or benefits from them - there is no substitute.
Infrastructure as Code’s biggest benefit is also it’s biggest challenge. That benefit is flexibility - because you are not locked into specific patterns and limitations of a black box product that only allows you to insert tidbits of code - you have full control. However, black box product limitations also provide a framework or scaffolding upon which you can build.
With Infrastructure as Code the challenge is that you must give sufficient thinking to how much “frameworking” you need build so that you can reuse, refine and debug an “engine” that does most of your work. If you are doing desired state type coding - it absolute requires an “engine” (framework) that processes bits of configuration data. Having to do your own frameworking is the price you pay for getting rid of the blackbox product in favor of full flexibility.
And you guessed it, frameworking or building engines requires structured coding and testing techniques to be truly successful.
The terminology “Borderline Developer” does at least two positive things for recruiters and candidates: [a] it gives credence to the fact that those of us who apply structured code to automation scripting are out there and we don’t need 10 years of C# or C++ under our belts to have hard core coding techniques, [b] it highlights an important distinction when sourcing DevOps professionals with an infrastructure background - they might be able to do some awesome code - but if they don’t know when to create functions, libraries (modules in PowerShell), adhere to coding styles and perform rigorous unit testing - they may not be suited for the more complex projects or teams who have to co-maintain code.
The term “Borderline Developer” was coined in Joe Sanchez’s excellent blog article titled “10 DevOps Skills: Finding the Elusive DevOps Engineer” - definitely worth a read.
Wouldn’t it be great if we could just learn DevOps the Matrix way: