Six months after LINQ to SQL was released, I had the chance to use it in a project. I was pretty excited. I was skeptical, too, but mostly excited. I figured I was dipping my toes into the future. From that day forward, there would be no need to write SQL (a fact that actually made me sad since I quite like writing SQL). Nope. From then on, I would write my database queries in C# like God intended. I was evolving. I was becoming a better developer. I was becoming a better person. (In hindsight, this was naïve. I still write SQL when it’s appropriate and I haven’t improved as a person since Three’s Company was cancelled.)
I dove in and got to work. Four months later, I released the first version of the product. It worked pretty well. It wasn’t perfect, but it was good. As far as I know, it’s still running today. Two things strike me from that chunk of learning.
First, it was slow. I’m proud of my ability to trudge through dense technical documentation, but it didn’t help much. I found myself paging through examples, trying to determine what was important. There are many ways to do things in LINQ to SQL. Trouble was, I didn’t know which were wrong.
Second, I entirely missed LINQ’s high-minded concepts. Wikipedia’s article on Language Integrated Query doesn’t waste any time before it mentions higher-order functions. LINQ was a baby step toward .NET functional programming and it was lost on me. I also didn’t recognize the magic behind transforming an expression tree into a SQL query.
These shortcomings were failures of relevance. I couldn’t identify what was relevant in documentation and tutorials, so I learned slowly. I didn’t recognize key concepts as relevant (I was too focused on immediate outcomes), so I glossed over them. People who learn quickly and fully do so because they understand what’s relevant. Learning disconnected facts is difficult and error-prone. Context is everything while learning a new skill.
Once you realize the importance of relevance in learning, you see it everywhere. AngularJS doesn’t have a steep learning curve because its owners are trying to outsmart you. It has a steep learning curve because it assumes you already understand model/view design patterns, two-way data binding, dependency injection, strict separation of concerns, and test driven design choices. Many people don’t. Angular’s context is big. Confused developers prefer blog posts, walkthroughs and tutorials to dry technical documentation. Even when a post simply summarizes documentation, it offers context. It decides what’s relevant. (Whether that decision is correct or not is another conversation.)
So how do we gain an intuition for what’s relevant? Let’s start with an uncontroversial definition of relevance: Relevance is how useful a given fact or concept is in solving a problem. If something is useful, it’s relevant. Given this definition, our quest for relevance boils down to collecting useful facts. Not surprisingly, this is how many people approach learning. They gather useful facts and apply them. While this seems sensible, it breaks down under scrutiny. For example, what do we do when we don’t know if a given fact is useful or not? When approaching a subject for the first time, there’s no way to develop a hunch. There’s no hint that we’re getting warm or that the trail’s gone cold.
(The only benefit we receive from our barebones definition is the realization that we sometimes have to roll up our sleeves and experiment. If, despite our best efforts, we can’t tell what’s relevant, experimentation is a sensible fallback. Can’t decide between Angular and React? Download them both and play with them. Then decide which works for you.)
We can enrich our definition of relevance by including relatedness. That is, relevance is also how, and how much, a thing relates to other things. If we know how things relate, we can move from a concept we don’t understand to a related concept and use what we know about it to determine relevance. That’s why people learn, say, regular expressions at different speeds. If you have a wide range of knowledge and embrace relatedness, you can use what you already know to speed up your learning. If instead you view learning as the memorization of facts, each new topic presents the challenge of the blank slate. Each new topic is an exercise in will power.
Which brings me to my unintuitive conclusion: The shortest path to understanding isn’t a sensible series of linear steps; it’s a meandering mess. What appears to be a needless side trip may actually be your brain completing a missed connection from its relatedness web. We need to stop worrying that every action in our day provides immediate business value. Build a prototype that illustrates how something hidden works. Learn an esoteric programming language. Start a side project that has nothing to do with your day job. Most importantly, follow your intuition as to what’s most interesting. Trust yourself to do the right thing.
Most of us like order. We’re comforted by sensible curriculums designed by people who are smarter than us. And why not? Sensible curriculums are great. Look closer, though, and you’ll notice something. The idiosyncratic details of your education weren’t defined in a curriculum. The weird bits that give your intellect its shape weren’t assigned. Instead, they grew from your decisions along the way: You chose the topic for your final paper and the decision changed you. You taught your computer to play tic-tac-toe instead of solving an easier assignment and it changed you. You tried something, failed completely, and it changed you. Heck, maybe you decided to skip the curriculum entirely and it changed you. This is learning that can’t be planned, can’t be scheduled, and can’t be duplicated for any other person.
It’s also the learning that shapes your unique web of relevance. Uniqueness is important. If all viewpoints are the same, they’re less valuable. A team with a complementary set of unique perspectives will outperform a team with identical views. Do yourself and your future employers a favor; quit focusing on efficient learning, because in the long run it isn’t, well, efficient. Take something apart. Teach someone something you don’t know yet. Tinker. Accept the fact that learning and careers are unpredictable and that they develop slowly. When you slow down, allow yourself to be distracted, and enjoy the distraction, you may find that you get where you’re going faster.
• Teach Yourself Programming in Ten Years
• Stanford study shows success of different programming styles in computer science class