“Code for the machine” vs “code for people”

Some code is for the machine. That is, maybe you write code to compute a big numerical optimization, or to predict whether AAPL will go up or down, or to multiply a zillion matrices and tell you whether this photo contains a bird.

Some code is for people. You want to let people share their photos online. You have a chat client that has complicated rules about whether to notify you. You want to give people access to your internal apps, but only people in department X get to see app Y, and so on.

(This is, of course, a dubious binary, but at least I’m not saying “one is good and one is bad.")

The primary skill in “code for people” is organization

Your application exists to do “business logic”; it has 400 layers of Frameworks around it to enable it to (run on the web/run on your phone/store data/control a robot arm/etc), but the reason for your app’s existence is that business logic. Most of the difficulty in “software engineering” is to make the right business logic available at the right time.

(This is why software is so goofy; if you build houses or something, at least you’re interfacing with wood and concrete and nails. If you build software, it’s as close to “just complexity” as you can get. Besides maybe law or accounting.)

Anyway, it’s kind of weird that people study Computer Science and then go on to write “code for people.” You need a dash of algorithms and data structures, big-O notation, databases, graph theory, networks, sure. But there should be a series of classes in the Computer Science curriculum with problems like:

• You want to store these 500 spices and pickles and things in your pantry; how will you build shelves?
• You’ve inherited an old library, a fire destroyed the card catalog, and you can’t use Dewey Decimal, what do you do?
• You’re coordinating an amateur theater load-in; you have 50 people with different skills, you don’t know what their skills are and neither do they, and the stage has to get built by midnight; how do you do it?