For years, I have had a picture hanging in my office. It is a semi-famous piece by the contemporary magical realist, Michael Parks. It shows a young girl blowing soap bubbles off the edge of a tall structure, and the stone gargoyles on the structure come to life. At some point during our time as mutual employees, I would call a developer into my office and instruct them to look at the picture. Take a couple minutes, I would say, and really look at it. Catalog in your head all the elements in the picture. Think about how it makes you feel, and what other ideas or images come to mind. After a few minutes of this, when they were satisfied they had seen enough (and I always knew they were wrong because of how quickly they were satisfied) I would ask them what they think the artist was trying to say with this painting. I would be met with a pained expression as the developer would then struggle to communicate to me that they saw a picture of a girl and a gargoyle and they were certain from the context that there was something more that they weren’t seeing, and that I was, and that their college courses on Computer Programming never covered art criticism, and this was a stupid exercise I was forcing on them anyway. I would try to walk them through it, ask leading questions as a teacher would, and eventually point out some of the things I was seeing.
For the last employee or two, I just stopped this practice as I was beginning to feel like an intellectual bully. To be fair, I am not sure I wasn’t. The point of all of this, though, was that I wanted to teach my developers an important lesson about reading beyond the literal to get to the ideas the art is trying to communicate with the viewer.
We all knew code. Some of us were stronger developers than others, but at the end of the day, those differences would probably be within a few percentage points on any reasonable scale of measurement, or else we couldn’t have been able to work on the same code base. But being a good developer takes more than knowing how to write a logical if statement. You must be able to read the requirements you are given and see beyond them to what the underlying problems are that the requirements are trying to solve. There may be better solutions than what the requirements suggest simply because the writer of the requirements wasn’t aware of those solutions. Likewise, sometimes, a request can be too detailed and if you take a step back you can see that there is an abstraction that would simplify the problem. None of these are situations that are resolved by a debugger. They require a human intelligence capable of abstract thought and symbolic logic and some impulses towards creativity. Though we can debate the merits of relative intellectual thought, this is no different from the processes that artists also go through for their own creations.
Today, I read an interesting article on Quartz, titled “Learning to code will eventually be as useful as learning Ancient Greek.” by Robert C. Wolcott. There were a lot of interesting points from this piece, but there is a paragraph that I want to quote as the most important.
“The need for humans to code will gradually disappear for all but the most specialized situations. Platforms will enable humans to describe in natural spoken or written language what they’d like computers to accomplish. The coding will occur behind the computational scenes. We won’t code so much as direct and request. Ultimately, coding isn’t the point. The objective is to define and communicate what we want computational systems to do.”
Here in the IT Community, we tell ourselves that while Artificial Intelligence will eventually put truck drivers out of work the same way the Internet did travel agents, someone needs to program those AI’s. Our jobs will change a bit depending on the technology of the day, but we will have job security because we understand computers. Please take a moment to pause while we smugly high-five each other. We don’t stop to ask ourselves why we would hold this shallow belief in the face of so much evidence to the contrary. Our field is destined for attrition, too.
There was a time when, if you knew a little bit of HTML and CSS, you could make a decent living creating websites. Then WordPress came along and put content management in the hands of the user. Configurable templates could be purchased and easily swapped out for $29 each. This was followed by website builders such as Wix. Just drag and drop your mobile friendly website into existence. No knowledge necessary. Now, all the successful website designers are really concentrating more on how their design compliments marketing. The website has been so heavily democratized that it is simply a means to an end, and the only value in the ability to create it is at the high end of the spectrum working for large corporations whose needs are not met by a user-friendly platform. All software development will follow this pattern. Don’t believe me? Take a look at any toy catalog and see how many toys offer to “teach kids the important skill of coding,” by using simple visual and tactile aids to represent commands and decisions.
So what does all this wool gathering lead up to? I don’t pretend to know what the future will hold. I am fairly certain my coding skills will still be useful for the remainder of my professional carrier. I am getting old an grey anyway. But I have no doubt that the nature of programming is going to change within the next decade or two, to become more heavily democratized as we build better and better abstractions and automations. I think that, while understanding computers will always be important, understanding problems and thought will become even more so. The programmers of tomorrow need to understand the business at least as well as they understand the computers. The programmers of tomorrow will need to be able to analyze problems and suggest solutions not just to project stake holders, but to the ‘bots writing the code. They will, in effect, become Process Artists. And they need to get started on developing those skills today.