Perspectives On Programming
James Hague recently posted an interesting article on his blog, Programming in the Twenty-First Century, where the he’s lamenting the difference between being the “inventor” of something that software is being used to solve, and being a “programmer” building it for the inventor.
I suspect this is why people always seem to be looking for “coders” these days. Even the terms “design” and “designer” have been co-opted by graphic artists, and now represent people who work with UI features rather than internal software design. Coders study somebody else’s idea and “design,” then write code to implement it. Never mind that this might take a bit of architectural and internal design skills … nobody really seems to care about that part any more — it’s assumed to be part of every coder’s skill set. Sadly, this isn’t usually the case. Most programmers are heavily left-brained thinkers, and such folks are typically very poor at dealing with abstractions and “big-picture” visualizations.
So for most jobs today, employers are looking for people who have mastery of TOOLS, rather than an understanding of the underlying principles. I guess tool experience now serves as a proxy for some vestige of understanding of principles involved.
The Software Development Life Cycle (SDLC)
Virtually every job req I come across today for so-called “senior” developers (meaning 5–10 years of experience) says something about “has extensive experience with entire SDLC.” (Hey, nobody advertises for “seniors” as in 50+ years old or 20+ years of experience!)
Software development hasn’t changed much in 50 years, although the various steps have become more clarified. Charts like the one to the left capture the essence of the problem from the perspective of a CIO looking at investing in the creation of an internal software system.
Notice that one across the bottom that says, “Change Control Process”? This is one that’s been around forever. Many companies choose to ignore it, rationalizing, “this is something developers do anyway”. So why have dedicated teams of specialists to it? Well, it turns out that without a lot of automation, the dedicated teams of specialists are far more efficient and accurate than a random bunch of programmers given the same tasks. Many if not most companies have never been willing to admit that. Luckily, automation has come to the rescue.
However, once automation is involved, then you need a team of developers to manage the tools instead of doing the work. Well, at least the work has been taken out of the hands of the developers and made more consistent!
I’ve been doing this stuff for 30+ years. Back when I started, it was simply called “managing our builds”. I did it for nearly six years with two different companies. Originally, the people who did it were typically called “librarians”. But it required a lot of tools be built in order to automate things that mere “admins” couldn’t do, so they’d hire a programmer like me to work with them.
At my first job doing this, my assistants, the “librarians” were slowly taken away to focus on other things. In order to survive and keep the workload manageable, I realized I needed to create tools to simplify and automate things. At the second job, it was just me, and I was hired to build a fully integrated bug-tracking / version control / build / automated test platform. It was pretty slick, and did what a team of four “librarians” had been having a challenge doing reliably.
After a while, this came to be called “build management”, “software configuration management”, “build and release management”. Today it’s called “DevOps” a contraction for “Developer Operations”.
It’s still the same discipline, employing the same techniques to accomplish the same goals with the same kinds of tools. The tools employed have changed every 5–7 years.
Back when I started doing this kind of work, I had to roll all of my own tools. Then I discovered Unix and found out I’d reimplemented a bunch of stuff that was already provided as standard shell commands, although I did invent a pretty slick distributed make system.
Then version control systems (VCS) began to dominate things for a while, and you had to have experience with one specific tool or another to get a job doing this, even though they all did the same basic thing.
Today there are even more and different tools being employed, like chef and puppet. And instead of knowing a particular VCS, you need experience with a hosted system like github. And because they’re mostly open-source, they employ a handful of different languages and mechanisms, instead of being a single monolithic platform provided by a single vendor (unless you’re a “pure” Microsoft shop).
It’s all about the tools today, and we “coders” are just mechanics building someone else’s stuff. In the DevOps world, that “stuff” is defined by some IT manager to ensure corporate policies are being followed. I could give an impromptu 6-hour lecture on the principles behind this stuff and the underlying choices an organization faces in terms of how they can manage their processes. But without a few years of hands-on experience with the specific tools a given team is using, there’s no job to be had.
This is a strange side-effect of having worked in this field for 30+ years … it gives us “senior developers” with several decades of experience a true bird’s-eye view of things that people with only one decade under their belt simply don’t have. I can’t tell you what the various tools in that graphic do specifically; but I can identify a couple dozen specific tasks that need to be performed, in what order, and how critically they depend on each other. You’re free to plug your favorite tool into each slot. Show me a tool; after studying it for a few minutes, I can tell you where it fits into the SDLC / DevOps process spectrum and most of the functions it’s going to provide.
The question I have is this: when will we start seeing job reqs saying they’re looking for people with 20+ years of experience, rather than just 5–10? And when will companies start hiring people to be “mentors” who’ve got at least a decade more experience on everybody else there, rather than just a couple of years?