Jennifer Nordell
writes on September 6, 2017
If you’re anything like I was two years ago, you just read that title and thought ”wait, what? Learn to code by teaching?” On its face, it defies logic. How can you possibly learn by teaching or helping others learn? What would you conceivably add to your knowledge base and skill set by explaining something you already know how to do? When I first started answering questions in the Treehouse Community, I did it because I wanted to give back to the Community that had helped answer my questions. I honestly never considered the possibility of learning about code by helping others learn about code. Having answered over 2500 programming questions from other students, I can tell you what I’ve personally learned by helping others.
Contents
The Cliché
You’ve probably heard it said a thousand ways: “Everyone has something to teach.” Now, what if I adjusted that to read: “Everyone who has written even a small program successfully has something to teach about coding”? The statistics are on my side. According to the 2017 StackOverflow Developer Survey Results, approximately 40 million people visit them every month. An estimated 16.8 million are professional developers. If you’ve passed a few coding challenges, taken a course in some programming language, or ever torn your hair out at a compiler error and still managed to fix it, congratulations! You know more about coding than 99% of the world. You do have something to teach, even if you’re still learning.
Have you ever had a scenario like this happen? You pour yourself a cup of coffee and set the coffee mug on your desk. You walk over to a co-worker to ask something and return to your desk. Now suddenly you can’t find your coffee cup, so you do the reasonable thing and ask your coworker if they’ve seen it. They respond with: “It’s on your desk, right behind you,” but you swear you just looked there. This type of thing happens to us all on occasion. It’s your mind playing tricks on you. There’s a name for it. It’s called a mental scotoma or “blind spot.” The second you think “I can’t see it,” you now are incapable of seeing it. Tony Robbins covers this in his book, Unlimited Power: The New Science Of Personal Achievement.
This phenomenon becomes more pronounced in a discipline where a single space or punctuation mark can break your code. At this point, an extra set of eyes is what is needed. By training yourself to spot the error in someone else’s code, it makes it easier to spot the error within your own.
I’m sure most of us have at some point in our lives played a “Hidden Object” or “Spot the Difference” type game. I’m always reminded of these when confronted with a fellow student who has code that isn’t compiling or isn’t passing a challenge. The first thing I look for is syntax errors. It is exceedingly common to misspell a variable name, forget a semicolon or one of a thousand tiny things that can make your code seem to fail arbitrarily. Nine times out of ten it isn’t giant logic flaws that get us; it’s the tiny details. Challenge yourself to see if you can spot the detail that’s off. The more you do this, the more efficient you will be at debugging code and common mistakes.
Code Objectivity
One of the greatest benefits to answering questions on forums has been that I’ve gained a certain amount of objectivity to my own code. I no longer immediately panic the first time I see a compiler error or the first time something doesn’t work as I thought it would. Having answered many questions about a myriad of different programming languages, I’m now familiar with many compiler errors and common mistakes.
I believe that it’s because of my familiarity with the most common mistakes that I can get up and walk off for a few minutes and try not to think about it. When I return, I try and pretend like it’s someone else’s code I’m debugging. I am essentially playing the “Spot the Difference” game with myself.
Helping Others Isn’t 100% Selfless
When I first started answering questions on the Community, I usually left an answer and a brief explanation. This method of answering went on for a while until I started getting secondary questions about the “how”s and “why”s. These were significantly tougher and required more time to answer.
Around this time, I began to notice answers posted which were just working code with no explanation. This practice irritated me somewhat as there was no guarantee that the already frustrated student would review the code line by line and learn what the code was doing. It was then that I began to feel obligated to expand my answers to include why my code works, and theirs doesn’t. Sometimes I would explain a concept or possibly even why we would need this thing in the first place.
I have answered questions that have forced me to go through the code line by line. I’ve had other answers that required me to dig through documentation, forum postings, and known issues. Besides being valuable for just that answer, it also has made me more confident in finding answers from other sources for myself and working out logically how the code is working and why it is working that way. I have posted many answers where I suspect that I learned more about the code by teaching than the person who asked the question.
Feed the Curiosity Monster
It’s not enough to be curious about programming. You must stay curious constantly, so if you truly want a better learning experience, take a look at questions that are outside of your current knowledge base. Maybe it’s a syntax error and you can help, or maybe not.
When I look at coding questions that are outside of my skill level, I try and challenge myself to see if I can understand what it’s attempting to do just in a general way. After that, I keep tabs on that question. Eventually, someone is likely to answer it, and I want to know the answer. I’m forever curious. If I’m lucky, the answer will come with a detailed explanation. I might not understand it all right then, and that’s ok. Seeing the question and the code with it seems to make it easier to follow along with the course material when I get there. It doesn’t feel nearly as alien and intimidating because I’ve at least had exposure to it.
[Tweet “”It’s not enough to be curious about programming. You must stay curious constantly” @jcnordell”]
Making Friends with the Documentation
I don’t know about the rest of you, but when I first started looking at programming documentation, it was flat-out intimidating. I could hardly understand what they were trying to get across. It contained lots of words I didn’t know or only had a vague idea of what they meant. It wasn’t until I started answering the questions of others that I began to think of the documentation as being on my side.
In many cases, I sincerely needed the documentation to be on my side. I can’t count the number of times I’ve received a question with a “how” or “why.” I know I’ve learned it before and I may know it to be true. Remembering where I heard it or the example I saw becomes difficult to pinpoint. I genuinely needed the documentation to be my witness so that I could point to it and say: “It says it in this paragraph.”
“Soft Skills” are Hard
Besides increasing your skill with coding, helping others on a consistent basis increases your communication skills. I don’t believe anyone is friendly all day long every day. We all have rotten days. I may have been working with some code that isn’t behaving the way that I want for an hour. I’m tired and frustrated, but now I go to the Community and see questions by students who likely feel exactly the way I feel right now.
Many questions come from beginners just starting to learn. No matter how basic I might consider the subject matter to be, I remind myself that there was a time when none of it was basic. At one point, I was right where they are. A few kind words and a little encouragement can go a long way. I know this because I received this when I was starting, and it was
tremendously appreciated.
Perception is key. I’ve repeatedly seen examples where two students have posted answers to a question, and both are equally correct. However, the one perceived as friendlier or more explanatory will usually receive the “Best Answer.” I try and avoid markdown and emojis that might be misinterpreted as sarcastic, condescending or even aggressive. I do, however, include a small amount of emojis that convey a friendly tone and markdown that is appropriate for the situation. The tone of your answer could be the difference between someone sticking with it and giving up altogether.
Don’t Rewrite History
I have answered hundreds of questions with over 1k chosen as “Best Answers.” However, not all my answers are correct, and some of them are only partially correct. In most cases, I will not remove them. I like to own my mistakes because they are part of the learning process. Many of them have spawned a discussion where I was ultimately proven incorrect. That’s terrific! We only learn things by being wrong. I’m ok with being wrong if I can learn why I am wrong. What I’m hoping is that others learn from that discussion in the same way I have. All of these things reflect what I’ve learned in my effort to help others.
Challenging yourself to provide top-notch answers with detailed explanations can be even more difficult than the coding problem at hand. Providing a simple answer that can be copy/pasted to solve a problem isn’t ideal. By posting an answer with no explanation, there’s a good chance that the student will not review it to learn why or how it works, and there’s a 100% chance that you’re cheating yourself out of a learning opportunity. If you feel like it might be helpful to reinforce your knowledge base on a consistent basis and to go deeper into the how and why of some solutions you’ve encountered, I can’t recommend helping others enough.
Jennifer Nordell is a Treehouse student, moderator and valuable member of the Treehouse Community, where she has helped answer hundreds of students’ questions. Jennifer has an incredible drive to learn and has racked up over 100k points since learning with us. We were so impressed by Jennifer’s incredible progress that we asked her to share her valuable experience and advice with other aspiring developers. You can read her inspiring story here.
Start learning to code today with your free trial on Treehouse.
https://blog.teamtreehouse.com/tips-wish-known-learning-to-code
