Does Everyone Need to Program?

I encountered my first computer in 1975, when I was in middle school. It was a PDP-11 workstation, about the size of a mini-fridge, that was shown to my scout troop as part of all of us working to get the Computer Merit Badge, which had in fact been established that very year. I taught myself how to program on the new Apple IIs that had been purchased by our school, three of them, kept in what had been a broom closet in the math classroom. This was augmented by occasional trips to Radio Shack to surreptitiously write porgrams on their TRS-80 Model 1 computers when the sales reps weren't around.

It was the dawn of the personal computing era, and the handful of us that had shared a passion for writing primitive games, making interesting graphical effects, and otherwise playing eventually all went on to careers in computer science - one went on to become a program manager at Microsoft before striking out to start his own company, another became a professor at MIT. I branched out into writing books and articles, learning about information theory and information management, and somehow never did manage to make that big score, but I've worked on some pretty high profile projects over the years.

Through high school and college, there weren't very many of us, though the number of programmers swelled into the eighties and nineties, until the tech recession hit in 2000. In 1998, everyone wanted to be a programmer, by 2001, no one did. The reality that most people who have been in IT for a while have discovered is that, with the exception of a few all-stars that happened to be at the right place at the right time, programming is hard work, requires a deep analytical mindset, and is not in general going to make you fabulously wealthy.

Nearly every hour that you are not spending actually coding is spent trying to stay current - to keep your skillset in line with what's needed in the marketplace. Guess right, and you'll make on average about half of what a medical general practitioner makes in a year. Guess wrong, and you're hamburger.

This is one of the reasons why I question why there is such a push on the part of political (and to a certain extent, non-technical business leaders to teach programming to everyone in middle and high school. First of all, there's a natural self-selection process that occurs - I think that you can tell who will or won't be a programmer by seventh grade. You can, today, sit down with Google or some similar search engine, and have all that you need to learn JavaScript or Ruby or Python or Java or PHP or fill in the blank other computer language within seconds.

The one who will become programmers will be teaching themselves about control loops and conditional logic and string parsing, and variables and all the other foundations of modern computer code by the time they are ten or eleven, and will be writing reasonably sophisticated programs by the time they get to high school. What they are learning is not only how to program, but also how to learn how to program, over and over and over again, and chances are pretty good they will be teaching their classmates how to write cool (and perhaps dangerous) code, far more than the teachers will be. This isn't surprising. Coding has always been a subversive art.

When such a young coder learns, what he or (increasingly) she is doing is learning how to think. Programming is not mathematics - in coding A = A + 1 is a perfectly reasonable statement, whereas it is patently silly to most people who think coding is in fact math. Actually, in truth are some deep mathematical underpinnings to programming - the above assertion is in fact equivalent to the statement "There exists an implicit function acting upon a domain that will map the value of the domain to one more than that value within the range, with the assumption then that the range becomes the new domain".

However, such received wisdom becomes evident only after the programmer has spent many years dealing with programmatic entities, at which point  that person reaches the need to understand the why of their actions, not just the how.

Indeed, what programming mostly teaches is analysis and problem solving- the ability to think, to break things down, then having done that to reassemble them in different ways to achieve a better solution or understanding. What's more, while the very highest end of programming does focus on algorithms - the most efficient way to sort a sequence of items, to navigate a network, or similar problems - most of these tend to be encapsulated in libraries of functions and routines.

Furthermore, the overwhelming bulk of all programming ultimately comes down to manipulating text. - searching it, creating it, modifying it. deleting it. A programmer generally works by identifying nouns - things, people, ideas - figuring out the adjectives that characterize those nouns, then figuring out what verbs those things can do. In effect, most programming involves the creation and extension of language to describe how things work, which are then used with other terms by the computer to actually make these things happen, at least virtually.

This is a specialized skill, and more it's a skill for which a certain aptitude and way of thinking helps a great deal. Can anyone do it? Arguably, most people can be taught to. Does everyone need to? Probably not ... at least not to the same extent that programmers do.

Alan Cooper, a UX designer and the inventor of the Visual Basic language, has written a number of books about software design. One memorable point he brought up is that if you give a person the choice when entering into an airplane whether they want to turn right to the seats to ride the airplane or turn left into the cockpit to fly the airplane will make the rational decision of going to their seats (assuming they don't immediately turn around and book their flight on a different airline).

Programmers, however, almost invariably want to turn left. They want to play with the dials and switches and buttons, want to challenge themselves to fly that aircraft better than anyone else could. It's perhaps no surprise that most people who buy flight simulation games are also ardent engineers and programmers.

After the tech bubble burst, many of the "programmers" who took a course or two in Java to go after one of the hot tech jobs left the field - they went into management, they switched careers, they took the money they had made and started their own companies. There was such a mass exodus out of programming that many colleges dramatically cut back on their computer science departments dramatically, because they couldn't fill enough seats to pay the instructors.

However, a core stayed. They continued to work in the field, often producing open source software because they were more focused on solving problems than they were in making money. They were in the field because of the passion of programming, the ability to play god in a limited way, to make magic things happen.

Now, tech is beginning to tighten labor-wise again, and the calls to make computer science a necessary skill - to teach programming at an early age, is growing with it. I think this is a mistake, for several reasons.

First, we don't need that many programmers. In 2002 (which was, unfortunately, something of an aberration) one out of every 200 workers was a software engineer or developer (https://en.wikipedia.org/wiki/Software_engineering_demographics), about half of 1% of the total working force. That may have inched closer to 1% thirteen years later, but it is still a minute percentage of the total number of workers. 

Moreover, much of that programmer workforce is very specialized. You need enough young people entering the workforce as programmers to insure you have adequate knowledge transfer, but typically it will be four or five years before even a fully trained developer will have enough real-world experience to contribute fully to writing software, about as long as it takes for a doctor, lawyer or manager to complete their full training and internship work. Programmers may enter the workforce earlier than doctors or lawyers, but most IT managers recognize that their junior programmers are going through what would be considered a journeyman period in an older guild society. It's why most programmers don't really hit their stride until their early thirties, as is typical of most professionals.

Beyond that, software development is shifting. Twenty five years ago, a huge amount of what was being developed was infrastructure - network protocols, operating system APIs, hardware drivers, compilers, the foundation of the web. Today, the bulk of all software activity has shifted to data manipulation and application development sitting on top of all of this, and is also becoming more oriented towards customization of existing applications. Indeed, one of the hottest professions in the technology sphere today is that of "data scientist:, which is not a software development position at all - it's what used to be called an "actuary" or "statistician", when the primary use for statistics was determining insurance trends.

Yet perhaps the most relevant reason for not jumping onto the programming bandwagon has to do with the fact that as software becomes more specialized, gaining proficiency in the tools of a given sector is more important than learning generalized software skills (and in many cases can serve to teach these as a side effect).

If you're a typical teenager, it's likely that you've already become proficient in Photoshop or Gimp, Poser, a 3d package such as Maya, game design packages such as the Unreal engine, sound software, basic video editing tools, word processors, power point, or any of dozens of other tools. Most games contain their own customization layers, and if anyone has played a game for two to three years, they've already begun the process of tapping into those "scripting" layers.

If you enter into medical school, you will be dealing with bioinformatics software and statistics packages, expert systems, point of presence software and electronic health record systems. If you're a lawyer, you'll be working with online legal libraries and analysis tools. If you go into engineering, you'll be working with CAD programs, architectural stress modeling systems, survey systems, and similar products. The business intelligence sector is changing radically right now. Even in restaurants scheduling software, menu management, transaction monitoring, and CRM have become commonplace.

The point in all of this is that gaining proficiency in the software that you need to do your job is far more important than the ability to write that software in the first place. This is true even in the software industry, where software that supports the creation of software has been around almost from the beginning. Over time, software that offers customization capabilities have become the norm, but even there, most customization layers are very specialized to that particular product. 

Learning general software principles may help in gaining proficiency, but this is much like learning Latin before learning Spanish or French - it may help you understand a little better why the languages in question are the way they are and make it a bit easier to understand the new language, but that only holds true so long as the language you're attempting to learn is like the languages that you know.

So, given that, how do you encourage the growth of a technically savvy population? This may be one of those situations where mentorship offers the best solution, rather than broad-based training. Aptitude tests can identify people who have both the interest and the analytic mindset for further training, mentorship, or co-mentorship (advanced students teaching basic students), specialized software can be taught as part of the educational path in other areas.  In most cases, educational or trainer versions of such software is available for free or at reduced cost, and schools can take advantage of this to make such licenses available to students.

Put it more simply, do not force students (or people in general) to learn to code. However, give them the opportunities, at various points, to learn the software that makes the most sense to them, then develop communities of learning to help support those that want to become proficient in various tools. Teach good self-learning skill  - programmers and program users both need this skill far more than they need to know how to write a FOR loop. Those who have the passion to code will take advantage of those opportunities.

Build it and they will come.

Kurt Cagle is a writer, information architect and data scientist working for Avalon Consulting, LLC. He's been writing on software issues for twenty five years, and is teaching his daughters how to program games (though they're better at it now than he is).