Explaining What I Do For A Living

I had a friend once tell me that he didn't understand what it meant to program computers. He was not really a computer user, and was just getting ready to try email at the time. He wasn't a gamer, and frankly the whole computer thing seemed too weird to him. After all, it's a machine, right? How do you program a machine? Is it like choosing a darkness setting on the toaster? Typing data into quickbooks? What? That was many years ago, but it still sticks with me. Some people (most in fact) really don't know what I do. If I tell them, they don't know any more than before.

When most people hear "programmer" they think "IT", in which case I must be the guy who fixes network outages, distributes patches, and helps people when their machine crashes (admittedly, a weak view of what IT is about). But no, I'm not that guy. I love those guys, but I'm not one of them.

A cousin of mine took an introductory course on programming, probably in Visual Basic, I don't recall. He told me that what I do for a living is really easy, "just typing." Of course I do some typing, but I'm not employed as a typist. In fact, on my good days, the program I work on is net-negative in terms of lines of code. But then a one-semester course on music appreciation hardly makes one a symphony conductor, or even a musician.

A post on slashdot a while back asked how to disguise "think time" because people mistake it for slacking. Again, we forget that this is not obvious to non-programemrs. One follow-up from Ben Alabaster was useful

During their lunch break get them to do a simple task like as a crossword. Ask them to be conscious of the amount of time they spend reading/writing vs. the amount of time they spend thinking [or looking up the answer]. Tell them that this is exactly the same as the time you spend reading/typing vs. the amount of time you spend thinking and looking up answers.

Better still Sudoku because it can involve hours of trying to figure out where you went wrong and why none of your numbers add up. So while the task itself seems relatively easy, after all, it's just numbers in boxes it can take time. Get them to predict how long it'll take them before they start and see if their prediction is right - guaranteed it won't be. You can hit them with a double whammy for why your time expectations never quite add up either.

This is the only way I can really think of to get them to understand the way engineers work. I see lots of "those types just don't get us types" - people are adaptable, people can understand things if presented in a fashion they can understand, it's just that nobody's ever taken the time to present them with an argument they get.

I think it is a great answer. We don't type for a living, we understand, reason, mentally try different solutions, hypothesize, disprove, reason, and invent. If we already knew the solution, we would simply type it in and be done with it, just as someone who had already solved the sudoko puzzle could copy it onto paper in hardly a minute's effort.

The majority of my work, though, is in diving into a system I don't understand (having read only a small percentage of its total verbiage), learning enough to understand why it is broken, rearranging and rewriting things until they make sense, writing tests to prove that my understanding of the problem is right, making changes that should fix the problem, and testing that my changes don't introduce new problems, all within a system vast enough that no one person understands how it works. I guess that isn't so easy to understand.

I spend more time learning than problem-solving, and more time problem-solving than typing. Basically, programmers learn and think for a living, and type their solutions into computers.

I suppose the right analogy is that you are handed three pages in the middle of chapter 17 of a 40-chapter novel, and you're asked to make some plot changes in the next hour or so. There is no chance you can read the whole book and make the changes in time. You could ignore the book and make your little changes locally and hope it doesn't disrupt the overall plot line, or you can read the chapter you're in and wing it. Eventually you'll have a solution you believe in, and you can type it in... but you shouldn't dive in with a typewriter until you've assessed what's going on, and the first thing you type probably won't be "good enough."

But now imagine that the document isn't a novel, but a multi-million word legal contract. You have to be very, very precise. Any mistake might open the company up to lawsuits and issues and costly contract revisions. Now you have the idea.

A really huge crossword puzzle is still a good approximation of a software system. Any one letter of any word may be a part of several different words, and changing one word may force you to change several others, which might cascade out to several others as well.

Do you understand why solving crossword puzzles isn't "just typing", and why it's faster if you have partners and reference materials? Do you understand why you might spend more time thinking than writing, and why sometimes you need to walk away from it for a few minutes if you're ever going to complete it? Then you probably understand programming well enough.