It’s amazing how much of a role explaining code can play in the perceived difficulty (or easiness) of how it works or is meant to be used.
For instance, I love the way Martin Fowler describes design patterns because he rarely talks about the code itself, and he rarely describes the code as such. Code is just another language for representing the world…much like I can describe to you how my day was in English, Chinese, or Canadian… I can probably also describe it to you in C++, ActionScript, or HTML.
To become a good programmer, its really about understanding what situation it is you want to model. And that understanding really comes from writing that isn’t about the code so much as it is about the situation.
Fowler describes part of Event Collaboration (the whole event-driven model) as such:
“When I tell Zen I’m going out it queries the temperature sensor for the temperature, uses this information to figure out what coat I’ll need and tells the valet to get the down jacket.”
This gives you a real world picture of what the code is actually doing. And, even when he gets a bit more geeky, it’s still a pleasure to read. Talking about Request/Response v. Events, he writes:
“One obvious difference is that the events are sent to everyone else, not just those components that are going to react. The point here is that the sender is just broadcasting the event, the sender does not need to know who is interested and who will respond. This loose coupling means that the sender does not have to care about responses…”
Here, while he’s talking about the guts of event dispatching/listening, he’s not talking about events being “invoked” or things “performing” things on other things. Event listeners and broadcasters suddenly have a human quality to them. “The sender does not need to know who is interested and who will respond” is a much more descriptive, and personal, account of how events work. And, it allows you to start conjuring up how things work in your head not as a bunch of code, but as real tangible things.
Being able to write about your code is more important today than it ever was. Twenty years ago, programmers were those inaccessible guys in the basement, sodering wires while writing binary in order to get a colored-version of Pong to work. Today, we’re building things like Google and YouTube, software for hospitals, services for the elderly. More people are trying to code… and the way that we-who-currently-know-how-to teach those-who-may-want-to-soon requires a new standard of explanation.