Since I switched jobs about 6 months ago, I decided that I wanted to move toward writing developer documentation. Not only is the job market for this skill extremely hot, it’s also a challenging and interesting landscape to explore.
I’m currently writing a lot of code samples for a JavaScript SDK. Even though I’m comfortable with CSS, HTML, and a lot of technical topics, like designing and developing WordPress sites, I’ve had to ramp up on programming concepts. Learning JavaScript has been a great intro to programming because it’s very easy to test code. You don’t need a whole integrated development environment to build and run code. Basically when you load your browser, you can immediately see results (especially through the JavaScript Console).
While I feel more confident in reading and writing simple code snippets to interact with our SDK, I’m keenly aware that there’s a depth to JavaScript I easily drown in. I know that if I want to reach the developer-level knowledge for tech writing, I’ll need to become a lot more advanced in my understanding of JavaScript and other programming languages.
No matter what industry you’re in, there’s usually a degree of significant technical complexity to achieve. Creating easy-to-understand explanations of extremely technical subjects is a core challenge. How do you ramp up the technical ladder to provide this level of insight? How do you learn difficult subjects in order to write useful content?
You could buy a big book on “ACME Programming” (or whatever) and sit down to read it, but if you’re like me, you’ll tire out after an hour and lose interest. Things may start out seemingly simple but then advance into fuzzy explanations and eventually become incomprehensible, hence useless, hence neglected and abandoned.
Instead of approaching learning so squarely, there are other ways to learn difficult subjects with more productive approaches. Here are 7 techniques for learning difficult subjects.
1. Start with a real problem before moving to books.
Start with a relevant context (some real example from work, usually) and then move toward book learning, rather than going about it in the reverse order. Start with a problem you’re trying to understand, and then go learn all the concepts you need to understand it.
For example, if you see
$.each used in a code sample and don’t understand it, go read up on what this method does and how to apply it. If you go about learning the other way around, by perhaps beginning with jQuery functions that begin with A and move toward Z, you may forget all the concepts before you ever encounter an actual scenario where you use them. Having a real problem grounds abstract ideas in a real context, making the concepts meaningful and relevant.
There’s another reason to begin with real problems. While learning from books is helpful, books often remain at a high level and cover general concepts only, or the sample exercises don’t connect with real problems. I’ve read countless chapters from JavaScript books, felt like I understood the concepts, and then found myself totally perplexed in looking at a real sample of code at work.
There’s a difference between conceptual understanding and practical understanding. It’s kind of like the difference between understanding grammar and understanding how to write an essay. Sure grammar can help, but an essay involves more strategy and problem solving. There’s no cookie cutter pattern to follow. Even if you start with concepts, always move towards real problems. No doubt you’ll switch back and forth between the two domains.
2. Learn in short chunks (pomodoros) of time.
My brain tends to get overloaded whenever I try to cram in too much new information at once, so I approach learning through the pomodoro, or interval, method. Basically, set a timer for about 25 minutes and focus on learning a technical concept during that chunk of time. Then stop and do something else.
If you can get in several pomodoros of time a day, you’ll probably make a lot more progress than if you were to try to devote a whole evening or weekend to learning a topic.
The term “pomodoro” means tomato in Italian, and refers to a 25-minute timer shaped as a tomato. The guy who developed this interval method of learning coined the term “pomodoro” to describe it.
Learning in intervals also has other strategic benefits. During those periods when the timer isn’t running, you may still be processing and reflecting on the concepts you were learning in the background of your mind. By spacing out the pomodoros, you let the information process and sink in.
3. Remove mental blocks about your intellectual capability.
One of the best articles I’ve read on learning hard subjects is this Quora article by Marcus Geduld: How to Learn Hard Subjects. He says that people often try to learn something hard but then give up too quickly. We tell a story about ourselves that removes our guilt. We say, I’m just not one of those people. Marcus explains:
You don’t get to say “I’m one of those people” until you’ve tried and failed TEN times. You are allowed to say, “You know, maybe I can learn it, but I’m just not willing to put in that amount of work,” or “I don’t want to learn it THAT badly.” That’s fine. But you’re not allowed to claim, even if you’ve tried and failed six times, that you have some sort of learning disability when it comes to the subject. EXPECT to fail nine times.
It’s much easier to convince ourselves that we’re not cut out for programming or mathematics because we don’t have the knack for the subject, or because we just aren’t smart enough. But the truth is usually that people who do have the knack or a seemingly innate talent have put in a lot of practice hours in getting to that point (as Malcolm Gladwell, author of Outliers, would say, about 10,000 hours).
I recently had a conversation with a friend who is a programmer at Apple. I mentioned that I like to write in my spare time, and he mentioned that he often writes code in his spare time. He said, I’ve written a lot of code that no one will ever see, that’s just for me because I like doing it.
His statement kind of surprised me. Write programming code for fun, for the enjoyment of it, that no one will ever see, in your spare time? Before I dismiss my ability to learn programming, I’d do well to remember my friend practicing code in his spare time while I’m watching movies or playing basketball.
4. Get engaged by solving problems.
The previous point about finding enjoyment in the activity leads to another technique: get engaged. I was going to write something like, find a way to make X fun. But what does that really mean? How does JavaScript programming become fun? Do I wear a Mickey Mouse hat and pretend I’m a wizard on a web page or something?
No. Things are fun when they become engaging. And engagement usually takes place when you’re solving problems. So whatever you’re working with, figure out a problem to solve.
The other day I was riding the train to work, and I was completely engrossed in thought about how to solve a particular problem with the code. I ended up missing my stop — the first time in nearly 6 months of riding the Caltrain! Problem solving is engrossing and helps you forget that you’re even “learning”.
5. Learn the basics first, then the advanced.
Here’s another gem from the article by Marcus Geduld I referenced earlier: learn the basics before trying to master advanced concepts. Marcus explains:
The next thing to ask is if you’ve done the preparation. Anyone can learn Calculus IF they’ve first learned the stuff leaning up to it. Some people make the mistake of jumping straight to Calculus without first learning basic arithmetic. And by “learning,” I don’t mean just “getting it,” I mean feeling really confident about it. If you sort of get fractions, but have to constantly look up how to add them, you won’t be able to learn Calculus.It’s amazing how many people skip learning to play scales, jump straight to Chopin etudes, and then declare, “I’m just one of those people who can’t play the piano.”
JavaScript is like this. If you don’t understand variables and functions, it’s unlikely you’ll understand callbacks and loops.
The other week I wrote some code for a simple function, and I was feeling pretty good about it. I had a developer review it, and he decided to rewrite the code in a much more advanced way. I tried to understand the advanced code for a quite a while, but ultimately it remained kind of fuzzy, even though he explained it.
I realized that I probably wasn’t ready to understand it at my current level, so I decided (after testing the code to make sure it worked) not to beat myself up for not totally getting an advanced concept when I’m still a beginner. I know that after a while, techniques will come more sharply into focus. I’m not going to tell myself that “I just don’t have a talent or this subject.” Instead I say, “I have to master the basics before I can understand more advanced topics.”
6. Anticipate gradual change, not overnight brilliance.
There’s a lot to be said for gradual changes. We are a culture of immediacy, but it might take several months or years to accumulate the level of knowledge we want. We have to anticipate a gradual change, one that will hardly be detectable from day to day but which will start becoming more noticeable on a quarterly basis.
What if takes you three years to learn a programming language? if you can implement change, little by little, you will be amazed at the distance you eventually cover.
One tricky task is figuring out how to measure your level of knowledge. How do you know how much you know? If you’re dieting, you can score your progress on a scale. But no one can really measure the amount of information that you have.
You don’t know how much you don’t know. That’s the interesting thing about knowledge. If we did know how much we really knew, it might be depressing. As Socrates says, “The beginning of wisdom is knowing you know nothing.” Hence, when you start recognizing how little you actually know, you’re probably learning a lot.
7. Use questions to go deeper with knowledge.
Have you ever wondered how Einstein got to be so smart? Did he have more neural pathways in his brain? Did he neglect his family and friends to immerse himself in his work? Did he challenge assumptions and look at the world from different perspectives? I’m not sure. But I do know one simple technique for going deeper with knowledge: questions. I’m sure Einstein asked a lot of questions.
I think asking questions is the single most efficient way to dig deeper with knowledge. When you want to increase your understanding of something, start writing down a list of questions about the topic. When you get to 10 questions, stop and answer them. Use your most significant answer as a starting point and ask another 10 questions from that new angle. Then loop it again, using your most significant new answer as a starting point to ask another 10 questions, and so on.
If you do this a dozen times, you end up with some really interesting results. The kind of learning isn’t so much gaining new known knowledge, but rather seeing new applications and insights that others don’t know (in other words, moving towards brilliance instead of just knowledge).
I don’t often think this rigorously about the topics I blog about, but one time during my MFA program I took a really mundane starting point and tried to see just how deeply I could go using this technique. I ended up writing a really interesting essay (which I’m hesitant to reread — I’d rather just remember it), but one reader said she thought I was either crazy or a genius.
Figuring out the organization and flow of so many ideas is another challenge, but the basic tool to unearth the deeper knowledge is simply the question mark (it kind of looks like a shovel if you flip it the other way around).
Conclusion (or Beginning?)
As technical writers, we specialize in learning really hard subjects. If you’re not learning something that is challenging, then you’re probably not doing technical writing. If you’re documenting obvious things, then you’re probably not creating useful content for your users.
The sweet spot in technical communication, or rather, in creating information products, is to immerse yourself in difficult topics, to battle with code and other arcane concepts, and not only pull clarity out of confusion, but pull brilliance out of blah. You’ll need your brain in high gear to be successful at it, but you can also learn to be much more efficient by adopting these techniques:
- Start with a real problem before moving to books.
- Learn in short chunks (pomodoros) of time.
- Remove mental blocks about your intellectual capability.
- Get engaged by solving problems.
- Learn the basics first, then the advanced.
- Anticipate gradual change, not overnight brilliance.
- Use questions to go deeper with knowledge.
Finally, I want to note that struggling to understand a concept actually helps us write better help, because we don’t start with a set of assumptions the user might not have. The developer who knows the code so innately and can write it in his or her sleep may skip over key explanations and details that the user wouldn’t know.
As soon as you master a subject, the curse of knowledge hampers your ability to explain it to a newbie. But until you master the subject, you struggle to explain it yourself. So in some sense, a technical writer is forever trapped in a state of learning — not being a master, but not being a beginner either. Figuring out how to feel comfortable in that space is a key challenge. You only overcome it through a love of learning. Incorporating the techniques I mentioned will make learning less of a chore and more of a hobby.
via I'd Rather Be Writing http://idratherbewriting.com/2013/08/01/7-ways-to-learn-difficult-subjects-in-order-to-write-useful-content/
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.