Don’t make poets become programmers

Computers are now part of everything we do. Resultantly, there is a growing assumption that everyone is going to have to master programming in addition to their other skills. Just as there was a push towards “data literacy,” we are seeing a similar push towards “code literacy.”

The industry’s current approach to hiring reflects this shift and it is becoming somewhat problematic. In particular, we are seeing more and more companies taking the stance that, no matter your core job, being able to program is always going to be a plus.

This is a really bad idea.

To understand my position, let’s go back to 2009. My research partner, Larry Birnbaum, and I started teaching a class at Medill, Northwestern University’s School of Journalism, aimed at bringing computer science and journalism students together in cross-functional teams.  

2009 was also the year in which it was becoming clear that journalism was being massively disrupted along every imaginable dimension because of a combination of factors; Google (disintermediation), Craigslist (undercutting the monetization of classifieds) and the rise of Web 2.0 (everyone was a journalist). In response to this disruption, journalism students thought they needed to learn programming.  

Larry and I envisioned a different path forward. Rather than learning to program, they needed to develop the ability to work with engineers. In many ways, journalism was expanding beyond writing — stories were becoming multi-faceted products and journalists needed to become media product designers. They needed to be able to communicate functional needs to engineers who could execute against them and provide ongoing feedback during the process. This is a far more powerful skill than knowing javascript.

Of course, since 2009, computation and connectivity have disrupted nearly everything. And as a result, we are hearing the same siren song drawing everyone to the nirvana of programming training. The message is simple: Computers are the future and if you don’t know how to program, you will be left behind. Period.

If we step back for a moment, it is clear that we shouldn’t blindly follow the programming path:  

• Yes, computers are the future. There is very little in the developed world that is untouched by computation and their impact will continue to grow.

• Yes, we need more developers at all levels and all areas of work. If the number of people with computational skills does not increase, we will fall behind.

• And yes, there are powerful problem-solving skills that are also aligned with learning how to program, and these skills are powerful tools in a wide variety of areas.

We can all agree on these points. But it does not follow that in order to function in business and the rest of world, everyone needs to be able to write (or even understand) code.  

I do argue that everyone should learn how to decompose large problems into smaller ones, abstract solutions in a way that makes them reusable and think about the complexity of those solutions. These are skills that flow from training in “computational thinking” and make people into better problem solvers. But there is a huge difference between computational thinking and programming.

And these skills are only one component of a larger suite of reasoning capabilities. Everyone should learn how to avoid cognitive pitfalls such as functional fixedness and sunk cost fallacy and be able to think about innovation as defined by needs and goals and craft communication for impact’s sake.

These are essential skills that are rarely part of a software engineer’s training. 

The future workforce is going to require more than the ability to code — we also need people who are able to craft the next round of transformational products and services. 

For example, Uber’s success stems from effective use of technologies aimed at a product that is the poster child for disruption. It connected underutilized resources (drivers and cars) with users who were impatient with a locked down and highly regulated market. The Uber stack is essential, but the innovation that drives it is less the code base and more the product. When we hear people suggesting things like, “Uber for dry cleaners,” we understand that they’re suggesting a direct and flexible relationship between customer and server; they are not talking about code.

An even more timely example is Microsoft’s efforts to build out its chatbot platform. It is a reflection of the balance between engineering and product. The company’s chatbot team has developers but it also has improvisors and poets who shape the chatbots’ conversational interactions. The result is a powerful cross-functional team made up of experts able to leverage each other’s technical and linguistic strengths.

We all have finite cognitive resources. Imagine if everyone had to not only understand and reason about the problems associated with their own jobs (e.g. how are we going to get millennials to buy life insurance?) while also thinking about the data layer (e.g. how do I determine the probability of risk aversion associated with a given age?) and implementation (e.g. should I use pandas or statsmodels to do my regression analysis?). If everyone has to think about everything all the time, nothing would ever get done.

Yes, you probably need a boatload of new developers and you should hire them. But do not assume that all new employees should know how to program. There are skills that complement those of the developer that, depending on the role, trump the ability to write code.

Instead of having everyone learn javascript, it might make more sense for us all to take communication classes. Then, at least, we’ll be able to effectively talk with each other about the products and services we want to build as well as the way we are going to go about building them.