Frameworks and Foreign LanguagesPosted: July 7, 2008
I spent part of my recent vacation in Spain, and since I don’t really speak Spanish I was forced to get around by simply parroting certain key phrases. I always feel strange speaking phrases in a language I don’t really understand, since I don’t really fully understand what it is that I’m actually saying; I might be able to swap out a few choice nouns here or there (i.e. ask “where is the museum?” instead of “where is the train station,”) but my ability to do transformations that would be trivial in a language I really understood (i.e. “where was the train station?” or “how far is the train station?”) simply isn’t there. But despite all that, plenty of people are able to navigate around and vaguely communicate in foreign languages through simple rote memorization of common phrases, despite not really understanding what it is that they’re saying or even what the components are that make up those phrases.
The phrase book approach is entirely different from what you’d do if you were to take a class in a foreign language; in that case you’d start from the ground up with some simple nouns and a few common verbs, learning the irregular verbs as well as the common conjugations of regular verbs, and then gradually expand out to other tenses and an expanding vocabulary. That sort of learning is much more thorough and is generally what you need to really become fluent in a language that you intend to speak, but if you just need to get around for a week or two knowing a few key phrases is generally enough to muddle through.
Upon returning, I was taking some time to try to explain the PolicyCenter delegation model, a pretty complicated concept, to another developer when I came to the realization that perhaps I was going about things the wrong way. Just like there are two ways to go about learning or using a language, there are two different strategies for learning a framework: you can try to learn all the nuances or you can just learn the basic phrases, and only really dig in once it’s clear the commitment will be worth it.
The reality is that most people will learn a framework more via the phrasebook approach, where they’ll simply cut-and-paste-and-tweak their way to accomplishing their goal. Eventually, if they use the framework enough, they’ll put in the work to become fluent in it and understand why things are put together the way they are, or why you generally only use certain combinations of options. But just as it takes a long time to develop any usable vocabulary if you attempt to start learning a language from the ground up, with an investment that’s simply far too high for something you’ll only need for a week of your life, learning a framework inside out is way too time-consuming and presents an initial barrier to entry that’s far too high.
Unfortunately, many of us designing those frameworks don’t think that way: we put a lot of time into making sure the API is right and the design solid, and into testing things and making sure it all fits together and is flexible in the right ways while not being overly complicated, and we often unconsciously expect that the people using our frameworks will take the time to understand all those nuances and really learn the language rather than just copying out of a phrasebook. But that’s just not how it works, and even people that will eventually want to learn the full language will start out trying it out by copying and pasting examples. Without those examples, people just flail, the barrier to entry is too high, and much of the hard work of creating a great framework is wasted because it ends up being under-utilized.
Whenever I come across a general guiding principle for my development work, I try to come up with some simple catchphrase to encapsulate the idea, and for this one it’s “optimize for copy-and-paste.” If you want to create a great, configurable product, you can’t just drop people a toolset and some documentation; you have to give them a large, realistic set of working examples that do close enough to what they need to do for them to visualize how to get there. And you can’t just treat your example code as “throwaway” code that doesn’t need to be good, since people will be using it as their starting point, so they’d better be good examples that you’d be okay with having someone else use in production.