When I taught Latin and ESOL, it was super useful to have categories of words. For ESOL in particular, there are three main buckets that we’d put words into:
- Tier 1 words: These are simple words, concrete nouns and easy verbs, that are immediately understood. Words like “apple” and “seven.” Assuming you’re already old enough to count, teaching you another language’s word for “seven” is just a question of getting you to recognize and reproduce the sound and the symbol. Easy.
- Tier 2 words are words for linking concepts, words (or phrases) like although or so that. These words do not really lend themselves to dictionary definition. (If you want to see some really ugly, hard-to-read English, look up although or if in a dictionary sometime.)
- Tier 3 words: These are words that represent technical, discipline-specific concepts. Photosynthesis is a good example. It has a technically precise meaning in science class, and if I want to teach it to you, I need to be sure you recognize the sound and the symbol, and I need to be sure that you understand the concept at all.
The reason these tiers are so useful is that people learn the words in each tier differently. Therefore, teachers should teach them differently. For tier 1 words, you can just jam out something simple, repetitive association: flashcards, repeat after me practice, labeling pictures, etc. You need a lot of tier 1 words to be any good at a language, but they come pretty cheap.
Tier 3 words require a bit more work. You need to practice the explanation of the term as well as the term itself. For photosynthesis, we might label diagrams of plant cells, explain in general terms the science out loud, practice questions and answers about the science. We would also probably learn a pile of related words at the same time. Tier 3 words don’t make sense outside the context of their discipline, so teaching tier 3 words is really an exercise in bootstrapping context and concepts around a handful of new jargon bits.
Tier 2 words are the most interesting, because there’s almost no way to teach them except by example. “He studied hard so that he would pass the test,” or “Although Steve was very fast, he did not win the race.” Teaching tier 2 words is like a coaching drill. You show the students an example, ask them to do the example, correct their form, ask them to do more examples, have them listen to each others examples, correct their form and give more examples, for a while.
The other reason tier 2 words are interesting is that they are neglected. They are neglected because they are invisible to native speakers. I once saw a silly post that made a good point: It had a paragraph with a lot of words like leaf and left and face in it, and asked me to count the number of f’s that you could see. So I did, and I scrolled down or hit next or whatever, and I was off by 8. Eight. I am pretty good at distinguishing the letters on a keyboard at this point in my career, how did I miscount 8 f’s in a paragraph that had many 30 words in it? The answer: if.
The paragraph had the words if and of in it. I had been so focused on looking for f’s in the middle of words that I didn’t even see them. If and of are classic tier 2 words, but they’re so much a part of the language we can’t see them. Tier 2 words have a few interesting characteristics:
- We absolutely cannot have any intelligent conversation without them
- People who are good at using them don’t always see them
- They can only really be learned by example
In short, tier 2 words are a learning shortcut. Consciously drilling your tier 2 words will make you better at English (1) these words are crucial to the language and (2) most people only improve in their use by subconscious imitation.
The Real Question, then, is…
…what are the tier 2 words of computer programming? When we find them, they’ll meet these criteria (analogous to the three features above):
- They are evident in most good code or good design, regardless of language and problem
- Good developers will do them automatically
- They are learned by example
This list doesn’t give us a good answer, but it gives us some good search criteria. Basically, we’re looking for mistakes that newbies make, either in code or in their process of writing code, that experienced developers don’t make.
Some of the developers I’ve worked with have a lot of experience, and I’ve noticed that they do two things faster than I do:
- They guess what’s wrong when something breaks. That is, they have a good enough conceptual model of the process that the computer is running that when something goes wrong, they can guess where fairly quickly.
- They have a good sense of what code to write and what code not to write. That is, they can look at a problem and get a good idea of what’s “in scope” for this problem and what’s not; they instinctively following YAGNI.
Can we derive some common principle from these two things? I think they are both about scope and architecture. In order to know what broke, you need to know what systems are involved in a given process, and what preconditions each of them needs. In order to know what parts of a system to change in order to implement or change a feature, you need to know what systems will be involved in the process, and what preconditions each will need.
Wow, those two sentences are similar. We might have a winner then: Experienced developers quickly develop a sense for what goes where. Does the business logic belong in this class or that class? What draws the UI? What accesses the data?
The analogy seems to hold: abusing words like although and if violates unspoken, what-goes-where type rules of English, and is difficult for students to learn except by imitating examples. Violating YAGNI and digging into the wrong parts of a system to troubleshoot it violate the what-goes-where rules of software design, and are problems that mostly affect inexperienced developers.
So what’s the shortcut?
When I was teaching, the shortcut with tier-2 words was to explicitly practice good examples; this practice would accelerate language learning, and help students who were new to English start gaining on their native-speaker peers.
How can we practice our instinctive, what-goes-where sense for building applications? If we read a bunch of design pattern books, we’ll over use the design patterns. If we read books on architecture, we’ll become architecture astronauts and not build anything. So what do we do?
I think there’s only one good answer: We read other people’s good code. Find an open source application or website that you really love, and ask yourself, how did they solve their problem? Learn their codebase. What goes where? What decisions did they make? Try to reimplement parts of it. What problems the original authors had to solve?
So, reader, what do you think? Have you run across any knowledge that meets these criteria for a hard to articulate but important learning shortcut? More experienced readers, what would you tell us?
Till next week, happy learning!