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.
