Here’s your thought for the day: Programmers don’t really know how they program. I stared in bemusement at that simple claim for a couple of seconds, went on to read the whole thing, and then realized the truth of it.
I don’t really know how I program. I couldn’t describe it in a series of steps like I might be able to describe how I drive a vehicle, or even solve a math problem (whole classes of which generally have certain steps that, when followed in order, yield the solution like peeling layers off an onion). Come to think of it, I recall initially being thrown off in my first computer science classes in middle school when the teachers weren’t really teaching us how to program. They showed us lots of example programs and how they worked, but the real sink or swim moment was when you were asked to program something you hadn’t yet programmed before. No wonder so many students in my computer science classes were put off by it; they were being asked by their teachers to come up with solutions completely on their own, to a degree they had never yet experienced before in school.
Here is my general “process” when I’m programming something tricky:
- I think about the problem for awhile. If there’s a written description, I read it over until I grasp the whole of it in my mind, then I just kind of stare blankly at the screen. Sometimes I close my eyes. This can go on for a couple of minutes, so when I’m doing something at work, I’d rather not have the boss come in during these moments lest he think I’m not being productive.
- I start outlining how my solution will work. Sometimes I do this in comments directly in the IDE and flesh it out with code later; other times I just write it in Notepad, or even on a physical sheet of paper when I need to sketch something. If I have a good grasp of the problem, I might just keep it all in my head.
- I go research anything I don’t yet know that I will need to complete my solution. Generally this involves Googling. After many years of doing exactly this, I’ve become remarkably efficient at researching programming problems online. Oftentimes I have an API or some documentation in mind when I start my search.
- Here’s where the magic happens: I write the code. I can’t really explain it in any more detail than that. Oftentimes my planning was woefully incomplete (or just plain wrong), so I revise it as I go along on at this step.
- Testing, and then debugging if something isn’t working.
Kind of enigmatic, huh? I think I could do a decent job of explaining how the planning stage works (I identify the problem, then rack my memory for any prior experience I have with that sort of problem, combining various common programming patterns as necessary, until I have something that should yield the answer), but I can’t explain how the programming stage works. Even more problematic, sometimes I completely draw a blank when I’m planning out a solution, so I just go directly to the coding, writing out line after line until I’ve arrived at some code that vaguely does what I’m looking for. I couldn’t say how that works, and it’s not nearly as simple as “Here’s how to design the program, and then writing the code is a simple transformation process on the design.” No, it’s not even nearly that simple.
How would you teach someone to program? The only advice I can come up with is to use an iterative cycle of planning, research, coding, and testing until the problem is solved, and not necessarily in that order. Other than that, I would have to revert to teaching programming the same way it’s been done since time immemorial: by example. I guess I’d spend a lot of time picking good examples that cleanly illustrate important programming concepts. But at the end of the day that’s just showing what good programs look like and how they work, not how to actually program.
There’s a lot more artistry in programming than we computer nerds get credit for. It’d be like trying to teach someone to be a great painter. Yes, you can teach individual brush strokes and show students great paintings, but at the end of the day, that aesthetic and creative insight that separates a Van Gogh from an Adolph Hitler cannot be taught.