I’ve been programming in one form or another since I was eleven or twelve. That’s over two decades of coding. Not as much as some, but still more than most coders my age. I started with BASIC, learned only enough of the infuriating and overly verbose COBOL, and finally moved on to more useful languages when I was about nineteen.
It’s a mysterious process to some. Very often fellow high-school students would come over to my computer and look at what I was doing. They would look at the incomprehensible stuff on the screen and ask, “How do you know what to type?”
How does one answer this question? When I was young and socially inept I would try to give the questioner a little explanation about programming languages, which I think was a larger answer than they cared to endure. What they were really wondering about (but didn’t know how to ask) is how so much (seeming) gibberish can do something meaningful. The problem was that programming was a mystery to them. They were familiar with other complex tasks like playing the piano, building a house, flying a jet, or writing an essay, but none of them had any idea what programming was or how it worked.
The next generation doesn’t seem to have this problem. My younger brother (thirteen years younger) doesn’t know how to program, but he has some sort of grasp of the concept that these are instructions for the computer. He has some sort of framework to hang it on, and coding is not arcane magic to him.
But this ignorance endures in previous generations, and causes all sorts of professional problems when I end up doing work for a client who knows nothing about what coding is or how it works.
CLIENT: Quick! We need you to build a house by next Monday!
ME: Well, you don’t usually build houses that fast, but what sort of house are you looking for?
CLIENT: Oh, we don’t have all the details yet, but we know we are really going to need it by Monday.
ME: (Deep sigh) Okay, so give me some sort of rough idea. One story or two?
CLIENT: Probably one but we might decide on two later. I’ll get back to you on Wednesday.
ME: I kind of need to know that now. So is it going to be brick or wood?
CLIENT: Just make it an option.
ME: That’s what I’m doing.
CLIENT: But for later.
ME: Wait. You want to be able to switch between wood and brick after I build it?
CLIENT: That would be great, yeah.
ME: You can’t… I don’t… That isn’t… Look, it can’t be both. I just can’t. It has to be one or the other.
CLIENT: (disappointed) You sure? Okay then. I’ll talk to my boss and see what he says. I’ll get back to you tomorrow.
ME: I see. So how big is the house?
CLIENT: How would I know?
ME: How big do you need it?
CLIENT: Well, just make it as big as the property…
ME: Which is?
CLIENT: I’m not sure. We have a couple of properties we’re looking at. One is a half-acre, the other is a full acre.
ME: So you’re not sure what you want, what it should look like, or where you want it, and all you DO know is that you need a half-acre house by Monday?
CLIENT: Is that a problem?
ME: I really need to know these details.
CLIENT: Look, just get started right now, and we’ll fill you in on the details as we come up with them. I do have the details of how we want the roof to look, so you could start on that while you wait for the other info.
Keep in mind that this client is not a jerk, a moron, or a sadist. The problem is that they have no idea what I do or how I do it. When I tell them I need the specs of how the program needs to work, they will invariably tell me what they want the dialog boxes to look like. This is the part they see and understand, and this is the part they have in mind when they tell me what they want. Once the interface is done, then they can iron out all those “other details”, like what the thing does when you push all those buttons.
The hardest part of coding isn’t coding. The hardest part is getting people to tell you what they need.