Explaining computer programming

Have you tried explaining what you really do at your job all day? Saying that you're implementing features and fixing bugs is kind of like saying a writer writes down sentences and will remove some that don't make sense anymore. It simply doesn't do the profession justice.

Simplify

Being able to explain something simply is said to help one's understanding of a topic. We could all understand software a little better, right? I've tried a few different things, one of them being that I get to make stuff up all day. Have I ever created a ClaimValidationProcessorFactory before and know what that is? Nope. I just made it up. And it's going to production. This explanation is a start, but I don't think it captures the scope very well. Understanding the depth behind being able to make stuff up, and having built off of others' made up stuff is vitally important to getting a good gist of what software engineers fight with on a daily basis.

Calvin Ball

Enter Calvin Ball. This is a simple to learn game that is very complex - you just make up the rules as you go. It's interesting because each new rule has to coexist or build off of the previous ones. If you have a rule that says you must hop on one leg and another rule that says you must hop with two, well that doesn't make much sense does it? The trick is extrapolating that a bit. In a non-trivial game of Calvin Ball (aka your app), the number of rules can easily be in the 100s. Knowing all of them at once is infeasible, but that's the demand that's put on you. Mess it up and you have moments where your players are told to do contradictory things. In software engineering we call that a bug. To help us out, there's certain patterns and conventions. You don't make _anything_ up. We know ClaimValidationProcessorFactory is a Factory, which carries a heavy set of assumptions on what a CaimValidationProcessorFactory does. If it doesn't, well, the original engineer needs their hands slapped. It happens far more often than you'd think.

Suppose

In the software world, things are composed of many layers. Each layer is a kind of thought that starts with "Suppose...". Suppose we have a state that has two possible values: on or off. Suppose we have many of these states in a series. Suppose these state series are used 4 at a time. Suppose we have a means of looking at one of these groupings of states and deriving an action from it. Suppose off off off on means "take the next two groups of 4, and add them together - assume them as numbers, and place the result in a known place". Suppose our series looks like this: "off off off on off off off on off off on off". You might say "oh I see off off off on a second time, so it adds again!", but that would be wrong. You must treat them like numbers. We supposed that already, right? We just described how machine language runs on a computer, which all of our software is based off of.

What it's not

Computer programming is not construction/manufacturing, despite construction related analogies we do all of the time (build, construct, factory, etc). If it does feel like construction to you, well, you're doing it wrong.

Ending thoughts

It's still considered cool to not be a "computer whiz" just like it's cool to not be able to do basic arithmetic to balance your checkbook... somehow. Taking some of the mystery out of what we do by giving a simple explanation without actually having to teach someone how to code could help us rope in more bright contributors and expand the industry as a whole. How do you explain it? Are there other things you see people equating it to that are simply incorrect?