[Featured Guest Blog] The top 10 reasons why people stall out learning to program - by Tony, founder of Hack Reactor

Biography

Anthony Phillips is the co-founder of Hack Reactor, along Shawn Drost, Doug Calhoun and Tony's brother Marcus, who works at Twitter; they are figuring out how to teach people to be developers through intensive web development bootcamps. A short official bio:

Tony knows what it is like to be in your shoes. After spending years as a director and lead teacher of a language school in South Korea, his brother (Marcus, twitter) convinced him to quit his job and move to SF to become a software engineer.

Tony did every self-guided tutorial online, and within 4 months was able to land his first developer position. However, he quit to join the inaugural class of Dev Bootcamp. After finishing the program, he stayed with DBC to develop software, help students learn to code, and organize admissions.

Tony on Quora
Hack Reactor - JavaScript-focused web development bootcamp
Tony was kind enough to share his email at the end. Feel free to reach out to him! : ) Great opportunity

Interested in doing a guest blog post? We are excited about what you have to say, message us.

Codesum, previous posts about Hack Reactor
~ Curriculum interview and more
~ Curriculum and student projects
~ The Human Factor of Hack Reactor : instructors and time

Today's news in the beginner tech learning communities:

~ Find out more about how to get started with various technology by joining our online community ABCamp  today's content how to get started developing for CRM at Hackathons

~ Treehouse now has a class on Git
~ Code School now has a class on JavaScript
(please use our referral to support this blog)

Actual Content of the Blog Post

The top 10 reasons why people stall out learning to program

We see a lot of people who are learning to program both during our course and in the interview and pre-course periods.  Everyone finds a certain part of learning to program challenging, but we have noticed that some people fall off the interview schedule or struggle in the class and there have been some trends in the pitfalls that we see people falling into. 

I'll try to outline strategies for staying away from these pitfalls below, but some of them are just hurdles that need to be overcome with brute force.  As someone who has been through the immersive programming education process, I have found the reward of learning to program to be so great that I hope to smooth the road for people who, like myself, were mired in unnecessary anxiety.

1. “Why can’t I get this?”

           

The number one thing I discuss with struggling students is how much time they spend thinking about their status relative to the rest of the class or the rest of the world.

 In extreme cases, some people are spending half of their days dwelling with others on the bleakness of their understanding, or beating themselves up by pondering, "Maybe I can’t understand this.  Why can’t I pick this up as fast as other students?"

            There are two problems with this. The first is that it's depressing and these students tend to have a self-reinforcing downward spiral of anxiety. This can lead to people deciding not to work on programming for a particular day because it is so associated with the negative energy of 'not getting it'.

            The second is that it takes up time. Frequently I notice that people in this situation would probably be on track if they would simply take the time they spend worrying about not being on track and reallocate it to working on the code they are struggling with. This is frequently a very difficult task for this group of people because this particular line of thinking is their go-to thought when they don't get something.

            SOLUTIONS:

           

a.  At Hack Reactor, we tell people to completely rely on us to tell them if they are not doing well and need to worry.  We keep track of whether they are making good progress or not and ask that they spend zero brain cycles on figuring out if they are failing or succeeding, ahead or behind.  If you can find a mentor, have them do the same thing and check in with you once a week. I would suggest having them take on this responsibility and let yourself have a vacation from worrying.

            b.  Get a win!  Frequently people fall into this line of thinking when they are struggling with a problem.  Sometimes just putting down that problem and doing something you know you can succeed at will put you back in the right frame of mind.  Find a task in your project that you know you can ace or do some easy toy problems that you found on the Internet.  Either way, you will keep yourself from starting the downward spiral.

2. Guess-and-check debugging

            People who do not apply a process to their debugging will frequently find themselves very frustrated and assume 'she/he is not meant to program'.  One symptom of this problem is when a student cannot tell where the exact problem is, but is changing the code.  For example, sometimes students will get an error message about a method being undefined and will start to look up the correct usage of that method and tweaking it over and over again, without walking through the code and finding out where their expectation departs from reality.  Sometimes they continue to tweak their usage of the method, when in fact the problem is that the object they are calling the method on is not even the object they expected.

            It happens to be the case that applying a very procedural approach to isolating exactly where the bug is makes a programmer’s life not only easier, but more straightforward.  Building this process is something that each programmer has to do for him/herself, and there is as much art to isolating a bug as there is science, but continually working toward a process is a must for any newbie programmer.

            SOLUTION:

            a.  Force yourself to isolate bugs to a specific line, specific function, or specific area.  Only allow yourself to build a hypothesis for how to solve the bug when you have isolated it as much as you can.

3. No actual building

            One thing I hear all the time is that people are spending a lot of time learning, but not making progress.  In interviews, people will list out all the things they have done to learn on their own, and for sure these activities add up to a significant number of hours. 

However, when we actually start coding, it turns out the person cannot even write a function definition.  This comes from spending time passively taking in information without truly applying it.  It can feel like you understand what you are learning, but when you are forced to do it on your own, you may realize that you are actually completely dependent on the system you were learning from to hold up your understanding.

            This is one of the reasons that we use CodeSchool as part of our pre-course curriculum.  It has the passive learning piece that gives you the context to understand what you are doing, but then it very quickly asks you to do something with the knowledge, and you have to actually switch gears into doing mode.  The more doing the better.

            SOLUTION

Make sure your learning focuses around doing.  I suggest creating some project along side of your learning and constantly applying your learning to that project.  Do not count watching videos or doing exercises that have leading hints as progress unless they are accompanied by actually using the new concept to program/code something that works.

4. The Buddy System

            This one isn't so much a suggestion of what to avoid as it is a suggestion of what to attain. Get yourself a buddy. You will find yourself working much harder and you will be much more accountable if you simply find someone to meet with once a week and agree to having accomplished x,y,z by that time.

            Go a step further and pair with the person once or twice a week and you will see significant improvements.  Try to figure stuff out together and throw ideas back and forth. Coding can actually be an amazingly social activity and it can be very enjoyable and motivating to work on a project with another person.

5. Nail down the basics

           It can be incredibly frustrating for beginners who try to solve a problem, believe that their ideas are just not quite right, spend hours reworking their code, only to find that they were missing a parens somewhere or some similarly simple syntactic mistake. I think a lot of people start off losing efficiency in this way because they want to 'jump right in' and they don't want to lose time with less interesting tasks like memorizing syntax.

 A student ends up losing significant amounts of time trying to hunt down their minor syntactic mistakes and it detracts from the interesting stuff: conveying your ideas through code.

            SOLUTION:

            We recommend that beginners straight up memorize certain bits of syntax.  Go find a style guide somewhere on the internet and model your syntax after that style guide.  Make flash cards with 'iterate over an array called numbers' on one side and

                        `for(var i = 0; i < numbers.length; i++){

                                    //some code;

                        }`

on the other.  Then quiz yourself when you are bored or over breakfast and see if you were missing a `var` or your indentation was off and keep trying until you can write a for loop without even using your brain.  For the simple building blocks of programming (loops, function declaration, assignment, if/else, etc) it is better to know them to the point where you are on autopilot writing the skeletons of these building blocks and then filling in the meat of them afterward.

6. Trying to do things ‘the right way’

            This one is pretty self-explanatory. Many people see coding as a math problem, where there is a right way and a wrong way to any given problem or implementation. It's actually closer to writing in any other language than it is to math. There will be trade offs to any implementation and very senior engineers frequently argue over the merits of one implementation over another.

            SOLUTION:

            For beginners, just let it go.  Make the thing work how you want it to first, and then go back and refactor it to make it better. The wheel-spinning that happens when you try to conceptualize the problem perfectly before dedicating one step toward any implementation is highly inefficient.

7. Lack of a roadmap

            There are so many different things you could spend hours and hours learning. It's easy to go down rabbit holes and find yourself learning about bitwise operators when what you should be focusing on is how to put together simple programs. As you continue to add to the stack of things you have to read, more and more tabs build up in your browser. Eventually you get tired and decide to call it a day, not having even finished one of the small features you set out for yourself when you sat down. 

The skill of catching yourself right before you are about to embark on a learning adventure that will waylay you for 3-4 hours is something I have been building for a long time and still have not got a great handle on, but I get better at noticing when I'm about to depart from the task at hand. I try to stop myself when I notice it is happening.

            Another aspect of a roadmap is where to aim yourself. You could learn Backbone, Ember, or Angular, and that's just for front-end frameworks. Once you have a certain set of skills nailed down, knowing what the next logical step should be is rarely clear.

Knowing when to build a big project and really invest in it or when to iterate over a bunch of little projects to solidify your skill set is tough. Knowing which framework is going to make the most sense based on what you have learned so far is similarly difficult.

This uncertainty can lead to people spending hours on topics they need to eventually know, but don't need to know right now. It can mean they end up with a skill set with large holes in it.

            SOLUTION:

            If you have found yourself a mentor, it is a great idea to have them sit down with you and lay out a roadmap of technologies and concepts to learn and in what order.  If not, it's a great idea to go to meetups and ask developers what they think. Write it down and try to follow it as closely as possible, allowing yourself to be pulled off the plan only when it’s super fun and energizing.

8. Yak shaving

            Sometimes there are major roadblocks that beginners run into that are only tangentially related to coding. Sometimes what stops them from making progress is that their version of ruby is outdated and installing a new version is a major project because the compiler in OSX changed recently.

Sometimes they can’t get their database to set up correctly because for some reason the permissions have been set incorrectly. These problems are useful to learn how to solve and are important eventually, but I would argue that learning them can be delayed for a long time without too much damage, and that a student should avoid dealing with them as much as possible while they are a beginner.

            SOLUTION:

            Have a dev friend/mentor set up your dev environment OR go to a meetup and offer to buy dinner to the first dev you meet if they will help you set up your dev environment. I know this sounds like avoiding the problem…and it is!  Try to spend as little time doing things other than coding as you can. Later (probably when you buy your next computer) you can endeavor to set up your own dev environment.

9. Persistence and speed in debugging

            Students who are debugging a problem with their code will frequently have tried two or three strategies by the time I sit down with them.  This is great, but usually it has taken them too long to get through those two or three strategies.  They usually think that I will have some sort of intuition that they do not have and will see the problem immediately.

            However, what actually happens is the first two or three strategies that I have for how to find or fix the problem are exactly the same ones that they tried, but I do it in a fraction of the time. 

I don't think this is due to me knowing more than they do in most cases, I think it is due to both a process that I have for how to debug and a familiarity with my tools so that I can use them quickly to diagnose. 

For example, the fact that a student might use the mouse to click on the browser and then move the mouse to the refresh button and click on it to refresh their tests and then scroll down to where they have a failing test can make the whole process take up to a minute just to get some data back to help diagnose the problem!

 This process for me is as fast as 2 seconds because I use keyboard shortcuts to move to my browser and refresh. This may seem trivial, but when you add up the number of times that you need to move from browser to text editor and back, it can be very significant.

            SOLUTION:

           When debugging, do not get at all discouraged if your first hypothesis did not solve the problem or if your first five hypotheses did not solve the problem. Keep iterating and try as many different ideas per minute as you can while gathering as much data about the problem as you can. In addition to this, invest some time in shortening the loop between your text editor and your browser. Learn your tools and get to the point where you can move around your dev environment very quickly.

10. Find the thing you love

            Sometimes people give up because they wind up thinking "programming just isn't for me." It may be the case that programming isn’t for some people, but we have seen a good number of people who started off feeling that way, and then they started learning back end stuff, or they started learning front end stuff, or they started learning algorithms and their view on programming completely changed.

 Programming takes a significant down payment up front, and then there are lots of different directions you can specialize in. It's a great idea to try to find the topic that interests you most.  You may hate every minute of CSS/HTML that you have to work on, or you can stay up all night trying to make your algorithm slightly more efficient.  Once students find that thing or those things, they usually hit an inflection point and their learning accelerates and they become much happier.

I hope you found some tips in here that save you hours, days, or more of inefficiency in your adventure to learn programming. I would love to hear other pitfalls that people have observed and how they overcame them. Feel free to email me at tony@hackreactor.com for clarification on any of these points or if you have questions about your own adventure learning to code.