The Trainee
Somewhere, deep in the bowels of an international investment bank, there is a man. This man’s has spent the better part of 10 years performing essentially this job: download a file which was created the day before from an FTP server sitting somewhere in the bank’s network, import that file into Microsoft Excel, manually validate the fields, and perform rudimentary calculations on the data. Once he’s done this, the resulting spreadsheets are e-mailed to colleagues, where they in turn decide whether they like how the spreadsheet looks. 
Naturally, this guy doesn’t particularly like his job, and complains about the frustrations of browsing to the FTP site in Windows Explorer and download the file. Particularly since he must get past the protestations, sabotage, and simple incompetence of the resident Mordac, the “Quality of Service” policies in the bank’s back-office network (naturally, the directors’ telepresence gets priority over your FTP site), and the general fitfulness of Windows Explorer’s FTP browsing mode. Neither does the tedium of validation rules he must manually apply to clean up the original file (and how terrible the programmers who wrote the code which output it are), or the time it takes to run the calculations in Excel escape public ruminations.
One day, a young trainee with dreams of becoming an algorithmic trader is brought into the group. After hearing the story and witnessing this man groan about how he is spending the bulk of his workday performing this task, he looks at the spreadsheet formulas and writes a trivial script to download the file, clean it up, and perform the relevant calculations. 
He gives the script to the original gentleman who runs it and nearly bursts into tears, asking what he is supposed to do now that his job is redundant to a script?
The trainee wasn’t a programmer (I once explained that he didn’t need to open and leak a new database connection for every query), he’s just a guy who wanted to help out his co-worker—sympathy for the original gentleman’s eventual predicament notwithstanding—and was able to take a tedious task that took a decade of a man’s life away from him and turn it into something which required minimal time and effort (and could have been turned into zero time and effort with a bit more time on teh GOOG). If the original gentleman had known how to code he would have automated that job himself, well before it consumed his life and reduced his marketable job skills to something that a very small python script could replace.
§
The Assistant
An engineer and former co-worker of mine once asked if he could spend some of his time teaching himself to code, albeit in C#. I was his supervisor at the time, and since we both worked in IT and his code was (if I recall) something related to handling our copious firewall logs better, I told him of course. It took a bit of time, but he became decent at coding up some amount of automation for the gear he was administering. It wasn’t great (one of the professional programmers on the development team told me “it sucked”), but the mistakes weren’t any worse than is to be expected, particularly given the mistakes I made when leaning objected oriented programming. 
Of course, I freely admit to being an idiot, and don’t really trust the code I’ve written to work properly until I’ve either seen it work properly or at least figured out how to recover quickly if it fails miserably, so I could be overly generous.
At any rate, he taught himself enough to make a formerly tedious task of his quite a bit less so. A few months later, he was helping his future wife by automating another instance of the “copy a bunch of data from one Excel file to another,” which used to take her the whole day to complete. I don’t know if she ever actually used the code, but I’m fairly confident that she would have done so if she had written it herself.
§
DevOps
The current hotness among the trendy managers is DevOps, and it’s a culture which I’ve tried to nurture in all the places I’ve worked. After 7 years in professional IT, I’ve seen all the precursors to it and how they fail in all sorts of career-limiting ways. 
Developers who insist on logging into the production machine to start their app manually rather than relying on the workflow scheduler, and resist packaging their applications in a way that can be deployed automatically using existing tools in favor of scp’ing binaries to production hosts or live-editing the config files in the hours leading up to the start of the day’s trading (in finance, only consumer banking is a 24×7 operation).
It’s immediately evident who would choose to automate those sorts of activities: systems administrators who simply don’t have the time to scp files around to thousands of hosts or have otherwise tired of throw-it-over-the-wall games and losing good staff who didn’t change the mistaken semicolon on the fifth line of the 10,000 line config file into a colon, and didn’t validate the config using the tool that was checked into another repository last week that all the developers talked to death in their weekly meeting, but failed to tell the sysadmins about.
The other type is the developer who has properly recognized that scping files around and logging into machines to check if the semicolon was changed is a completely stupid waste of their time.
§
Backlash
I think most people who aren’t working in technology have probably seen or experienced something like the situations I’ve described. Pretty much any job that needs to do things at scale will involve a certain level of tedium like those described here, particularly jobs surrounding recordkeeping or retention of some kind. To give just one more example, one trend in discussions of health-care costs involves the insanity of those thousands of shelves of paper medical records you’ve undoubtedly seen, and how much better it would be if they could just be digitized. However, do you think those 300,000,000 records will digitize themselves? There will be an army of OCR robots scanning paperwork, and an even larger army of technicians reading over them to fix the mistakes introduced by the scanning robots. Unfortunately, not everone sees the wisdom of helping everyone learn how to code.
Firstly, some business people attempt to discourage fellow business people from learning how to code. I’ll simply come right out and say it: the C-level who knows how to code is more valuable to an organization of any size than the C-level who does not. I’ll take it a step further and say that folks who wear ignorance like a badge of honor are the folks that spent the last few decades mismanaging the American auto industry into nationalization.
Part of this is a non-coding bosses’ fear of subordinates who know more about how the business actually runs (in this case, because they wrote the code) than the boss does. It’s a fairly widespread notion, but I think it’s simply a failure to understand delegation. To my mind, legitimate delegation is allowing your subordinates to do things better than you could, and those that refuse to accept that are simply refusing to delegate. It probably also be noted that a manager who cannot truly delegate is one who refuses to allow their organization to surpass their own limitations.
Another part of it is, bluntly, laziness. Business people who go on record saying non-programmers don’t need to know how to code are—to my mind, at least—indistinguishable from employees telling each other not to work so hard lest the rest of the team look slothful. As non-coders, business people are at least theoretically aware that a CFO who can code is better than one who can’t, but they also know there’s a time limit on their involvement in business: if they can stall the wave of coding executives for another 20 years, they can retire comfortable in their ignorance, just as previous generations did with the ability to type.
Of course, these non-coding business people are being told that everyone needs to code by people like Obama and Bloomberg, who in turn are taking the advice of their technology advisors. The same advisors who have been pushing for H1B expansion based (at least in part) on Economics 101-inflicted brain damage: the idea that there is a labor market, and that if the supply of qualified applicants is increased, the price of a good programmer will decrease. Of course, like most things in 100 level economics courses, the real world rarely cooperates: wages are sticky, and any company that actually attempted to lower programmer salaries would get less-professional, less capable, less experienced, and all-around worse programmers.
So it’s amazing to me when I see professional programmers telling people not to learn to code. Professional developers have bigger challenges to tackle than scp’ing config files onto new hosts or writing VBA scripts, and they have no qualms about automating that tedium out of their jobs. Systems and network administrators have been doing the same for decades. Why shouldn’t business people have the same ability?
Unfortunately, that doesn’t preclude professional developers from also suffering from that same style of Econ-101 brain damage: “If everyone learns to code, the supply of available ‘programmers’ will increase, leading to downward wage pressure on my wages,” provided you make the quite stupid assumption that a Cartesian example featuring axes without scale can explain everything you need to know about human motivation and the global employment system.
This is not to say that some people will not feel the pressure of competition, but those people aren’t professional developers. The people who will feel that pressure are the terrible programmers. The kind of people that charge exorbitant consulting fees to generate in-house accounting monstrosities built on Access. Those guys will see their competition explode, and you’ll get a lot more barely-functioning ugly code doing the random crappy stuff that real programmers don’t touch with a 10 foot lambda expression.
My own perspective is that if a bunch of ugly code is the price to pay for liberating millions of office workers from the tedium of their job, then so be it.
And who knows, perhaps the demand for skilled programmers will actually increase as they are called in to cleanup the ugly code that used to do the job but no longer suffices.
James Cape 