Jim Nielsen’s Blog
Preferences
Theme: This feature requires JavaScript as well as the default site fidelity (see below).
Fidelity:

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Programming Pairs Well With Other Disciplines

Programmers know the benefits of everything and the tradeoffs of nothing. — Rich Hickey

I’ve been going back through and parsing the highlights I made in Clive Thompson’s book Coders. One of the connections that arose from my collection of highlights was the idea that programming in a silo very easily leads to unintended side effects. That’s quite often going to be the case and there’s not always something to be done about it. However, one way to shore up against the unintended side effects of technology is to pair programming with knowledge and theory from other disciplines.

In his book, Thompson makes a counter-point to the notion that a coding “bootcamp” is will teach you everything you need to be a good programmer. This notion, he suggests, overlooks the value of a more diverse education:

One benefit of hiring employees from nontraditional fields is that you gain their broader perspective. Eager computer science kids fresh out of college have little life experience. They easily fall into the naive, cocky belief that they can solve any problem—and often fail to even entice the real problems in the world that might be tackled with clever software, because they’ve not encountered them. And if they’ve studied very little of the humanities—history sociology, literature—they often have what Northrop Frye might have called and “uneducated imagination”: They have little ability to envision what motivates the users of their software. They’re great at grasping the binary soul of the machine but not the quantum weirdness of human psychology. (365)

Programming a machine is the easy part. Programming a machine with a group of people in order to tackle nuanced human problems with clever, sustainable software solutions—that’s something else.

Coding specifically, but perhaps technology more broadly, has this inherent culture of “just get it working” and then run with it. See what happens. Don’t really contemplate the effects of what you’re making, just try to get it working. Seems like there was a guy who said this once...

Screenshot from the movie “Jurassic Park” picturing Ian Malcolm with the caption “Your scientists were so preoccupied with whether or not they could, they never stopped to think if they should.”

As authors like Nicholas Carr have warned, there are always unintended, unforeseen side effects of technology. Thompson touches on this in his book. First he quotes Anil Dash:

The idea of mass organization around something, and sharing it on social media, that was a goal, something we wanted to enable. The idea of mass organization around a lie was not part of the narrative. (323)

Later Thompson expounds on his idea:

The first generation of social networks were built and funded by techies who regarded “connecting people” as the only goal, as dana boyd points out. They naively hoped that all the hard stuff—getting humans to actually understand each other, to bridge their big political differences—would happen automatically. It didn’t. It can’t. Merely creating “information flow”...isn’t enough. (boyd is particularly annoyed by Zuckerburg’s continual reference to the 2 billion global users of Facebook, comprising people from Texas to Islamabad to Jakarta, as a “community.” It shows his persistent misunderstanding of what community really is: a group of people who share a common bond and a common reliance on one another.) (335)

This gets at the heart of the notion that “everyone should code” because software is “eating the world” and is going to solve all the problems. Thompson quotes Jeff Atwood, well-known software developer and founder of Stack Overflow, who says

“[That is putting] the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?”

I’d like to take this to heart. I think maybe one of my goals this year is going to be to attempt to divert a substantial part of the mental energy I expend in “keeping up” with technology to, instead, broadening my own understanding of other disciplines and figuring out a way to synthesize interdisciplinary knowledge. Good thing I already have a place to air out my thinking: right here on my blog.