
The 2 Biggest Mistakes I Made When Learning to Code - suneel0101
http://www.suneelius.com/2012/09/07/the-2-biggest-mistakes-i-made-when-learning-to-code/
======
KirinDave
If you have been starting to write code and study code for a year, you are
still learning to code. You have not learned to code, you are not even a
journeyman yet.

I've been in the industry about 9 years, and coding since I was a child. My
parents caught me staying up late with a flashlight under the covers as a
teenager reading books on C instead of nudie mags. My first program with an
event-driven UI ran on a NeXT Color Station. This is not to brag, it's to say
I've been doing this basically since I could decide what to do, and I still
have a lot to learn about coding, computer science and software engineering.

So you've made your third biggest mistake; you've vastly underestimated what
you are in for. You have never "learned" to program, you are "learning." Every
year will ask you to acquire new skills and use new models and learn new
domains.

~~~
eitland
> So you've made your third biggest mistake; you've vastly underestimated what
> you are in for. You have never "learned" to program, you are "learning."

I am afraid your comment is even more mistaken. Even more it is discouraging
in a really bad way. Read carefully and I'll explain. Even if your HN score is
10 times mine.

In my opinion you are creating a false dichotomy between having learned and
learning. Someone who has just started to walk/bike etc has still learned to
walk/bike. They are by no means near entering Olympics for the next few years
but they have made their own life very much simpler and more enjoyable.
(Father of small children here.)

Comments like yours are discouraging at least one specific subset of people
from doing the one thing that can possibly help them increase their skills,
namely use them. I even think that for most people even if they can learn a
lot about coding by just reading, reading and immideately applying it is by
far a quicker route.

Anecdata: I once told a 16 y.o. intern how to use basic perl and Visual Basic
for Applications. After 14 days where he would run his scripts, check, check
with his supervisor, fix the code, learn more perl and vba and so on he came
back with a report that would have taken weeks to finish by hand. He is now on
his last year on a Bachelor with Honors study and this was his first useful
program. Still makes me happy.

(By the way, I also started coding at age 12. Having programmed for both $100+
million companies as well as startups I am not one of those struggeling to
learn the basics. Anymore, that is : )

~~~
KirinDave
> In my opinion you are creating a false dichotomy between having learned and
> learning. Someone who has just started to walk/bike etc has still learned to
> walk/bike. They are by no means near entering Olympics for the next few
> years but they have made their own life very much simpler and more
> enjoyable. (Father of small children here.)

The fundamental difference here is that bikes are ridden in a way that's
fundamentally unchanged for decades. Contrary to this "settled" field of
knowledge, programming is constantly invalidating itself. Even if you achieve
competency in a limited field (perhaps operating system design or web
development), that field will almost certainly overturn itself within 5 years
for any reasonably broad definition of field. Consider what modern linux looks
like compared to the original version; a lot of new techniques have emerged to
address requirements.

To enter that field, this new knowledge is not "optional." It's required. The
goalposts for competency aren't just shifting; they've got a nuclear power
supply and tank treads and they're out of control.

In this, it is not unlike being a doctor. Their knowledge base is similarly in
constant flux (although not quite so violently as ours). A doctor who does not
constantly improve and update their knowledge will be a substantially worse
doctor than one who does. A perfect example of this is pre-scientific doctors
like homeopaths, who basically do nothing with an almost frightening level of
dedication and fervor.

> Comments like yours are discouraging at least one specific subset of people
> from doing the one thing that can possibly help them increase their skills

I did not direct this at some 16 year old kid or a non-programmer, nor did I
put it in a venue where non-tech people read. Even if I did, citing final
consequence is hardly a good argument. In any case, the industry does a pretty
good job of discouraging people from joining as it is. When I was in college,
there was a 60% dropout rate between lower and upper division classes.

~~~
eitland
Checked your profile and you seem to be smart, yet I think you are wrong again
: ) (sure you have got enough sleep lately? not been talking to much to
marketers?)

> "The fundamental difference here is that bikes are ridden in a way that's
> fundamentally unchanged for decades. Contrary to this "settled" field of
> knowledge, programming is constantly invalidating itself."

The most well known styles of programming (imperative, functional, object
oriented etc) have been unchanged for two or more decades as well.

And a 10 year old c or html tutorial still works and still lets people start
solving real world problems.

I guess I'm leaving this discussion here. You know way to many cool
expressions for me: '

>"programming is constantly invalidating itself" - this holds true for Java, C
and Lisp right? Or are we talking about how for loops aren't valid anymore?

> "Consider what modern linux looks like compared to the original version;" -
> We are talking about that "unix clone" thing from early ninetys? Has it
> become a Windows clone without me noticing?

> "A doctor who does not constantly improve and update their knowledge will be
> a substantially worse doctor than one who does. A perfect example of this is
> pre-scientific doctors like homeopaths, who basically do nothing with an
> almost frightening level of dedication and fervor." - Comparing software
> developers to doctors. Go tell some doctors. Try car mecanic. They also have
> to stay up to date.

> "I did not direct this at some 16 year old kid or a non-programmer, nor did
> I put it in a venue where non-tech people read."

No, but you directed it at a new programmer who shared something that a lot of
people in that situation seems to struggle with. Hey, not just new
programmers, even Kent Beck has blogged about a similar situation:
<http://www.threeriversinstitute.org/JustShip.html>

~~~
KirinDave
> Checked your profile and you seem to be smart, yet I think you are wrong
> again : ) (sure you have got enough sleep lately? not been talking to much
> to marketers?)

I am not sure why you decided to include this toxic, thorny little jab in your
post. Please know that it's not appreciated.

> The most well known styles of programming (imperative, functional, object
> oriented etc) have been unchanged for two or more decades as well.

This is not true. The state of the art in all of these has advanced
considerably, and many things that were once considered good practice have
been discarded over time.

> And a 10 year old c or html tutorial still works and still lets people start
> solving real world problems.

I'm not sure what definition of "real world problem" you're talking about.
Certainly nothing I learned 10 years ago directly pertains to my work today...
Not pure math; its quite rare to use C for that sort of problem anymore. Not
networking problems, 10 years ago you couldn't write servers the way you can
today (nor should you save for perhaps embedded systems like
microcontrollers?) Not UI either. Perhaps simple text munging? Doing that in C
is pure futility compared to what we have today.

As for HTML, a 10 year old HTML tutorial would give you almost no insight into
modern webpages, and a very large amount of it would be "N-hancements".

> No, but you directed it at a new programmer who shared something that a lot
> of people in that situation seems to struggle with.

I'm not sure what your point is. Nor am I a huge fan of Beck's philosophy in
this.

------
at-fates-hands
I think the problem is a lot of people jump in, start coding and then never go
back and learn about the nuances of a language.

Case in point was myself when I was learning Javascript. Sure, I could get the
JS to do what I wanted, but it was clunky, used a lot of memory and was slow.
Fast forward a few years and I've gone back and read Crockford's books several
times, and with more studying, I've gotten much better at writing JS. I now
try and make my JS as lean and as fast as possible. It's a totally different
approach then when I started.

The problem is thinking once you know how to do something, you're done. Like a
friend once told me, "You don't learn to be a programmer, you learn to be a
student of the language you choose."

~~~
dwoot
You make some valid points.

However, had you not taken the road you did, the material you read much later
on probably wouldn't have made much sense and probably could have made you
turn away from it all right at the start, right?

You get excited when you see results right away. Once you do enough things
that begin to make you wonder, "Gee, there's gotta be a way to do this faster
or more efficiently." When your curiosity drives you to search for answers is
when you delve much deeper into the nuances and the grit of a language that
becomes important for scale.

~~~
suneel0101
You're right, there's always some retrospective bias, but I'll never get back
those days of reading about PHP, since reading Python accomplished the same
and actually was much nicer for a beginner. The truth is, your MVP will evolve
and will require you to learn things, new languages and new technologies. The
fun is never over. For me it's continuing and im so glad of that.

------
sophacles
I don't know that #1 was a mistake. When getting into any new field, it is
very hard to tell what is important and what isn't, what is a solution to the
problem and what isn't. If you are in school, sure they'll guide you, but if
you are self-learning, there is no really good filter. So learn about
everything. Take a breadth-first approach. Some of the specifics you learn
will be wrong, useless, or otherwise inappropriate. However, getting an
understanding as to why they aren't relevant is in fact _learning the field_.

The more information about a topic you have in your head, the more likely you
are to see the connections between subfields, how various bits are important
and unique or just ho-hum standard implementations.

I regularly see people in some niche area say "look we have found this amazing
new way to handle the data-flood", only to tell them they have reinvented
NoSQL or a message queue, or a technique for dealing with matrices that the
image processing or simulation folks have been doing for years (and all of
them poorly, making recognizable mistakes). A breadth-first overview has much
advantage.

~~~
xster
Agreed. It's easy to look back and know what were needed in retrospect but
it's hard to even know which is for what until some time is spent to learn its
capabilities

------
bitwize
Step 1 in learning to code:

10 PRINT "COCKS"

20 GOTO 10

Step 2 in learning to code:

10 INPUT "How many cocks do you want",C

20 FOR I = 1 TO C

30 PRINT "8===========D"

40 NEXT I

I'm not recommending that your first steps into programming be in BASIC, or
involve cocks. (On both accounts I would recommend the exact inverse.) But
this is how a million programmers got started: useless programs that amused
us. Never, ever, ever underestimate a useless program, especially for
beginners. The author of this article seemed to want to focus on building a
prototype for his Web startup. And that's fine, as a long-term goal. But if
you're brand new to the world of programming it's probably a good idea to
start with the basics, like printing or drawing stuff on the screen, doing
some simple (or, later mor complicated) mathematics, or munging or
transforming data in interesting ways. This helps keep the budding programmer
focused on the patterns and "shape" of their language, which knowledge they
can then later direct to a specific purpose like Web or smartphone apps.

~~~
pbreit
I totally disagree. I can't stand tutorials or classes that present useless
stuff as exercises. It's so much easier to work on something that you can at
least imagine would have some value. And it is much, much easier to work on
something that you think is either cool or have always wanted to build, etc.

Also, 1/2 a downgrade for the lame, childish example.

~~~
olliesaunders
Your standard for the importance of things being useful might be slightly out
of perspective when you consider the main goal here is to learn: when you
first start programming it doesn’t matter what the program does just as long
as it did _something_ , you understood it, and you can build on that knowledge
to the next thing. That’s why we start with Hello World.

~~~
eitland
Still I think his point is relevant. For a lot of people the fact that
something is useful contributes a whole lot to the motivation for learning it.

~~~
pm90
He said "...useless programs that _amused_ us" I think that everyone missed
the "amused us" part. If your program is useless but still does something that
you think is amusing, then that is a great feeling

------
albumedia
Congrats on learning to code but the biggest mistakes new hackers are making
is diving right into learning a specific lang.

Learning programming fundamentals is a better way to go. That way, you can
jump from lang to lang.

Starting is hard so congrats again.

~~~
asolove
I disagree. You didn't learn to talk by studying rhetoric. You imitated sounds
and words that people made around you. Then you started being able to express
your own ideas. Then, maybe, you learned how to say things well.

It's the same with computers. While some people may enjoy learning deductively
about abstractions like algorithms and paradigms, studies have shown that most
people learn inductively, by having something they want to do and figuring out
what to do.

~~~
jemka
Human speech is a bad analogy. A better analogy would be grammar and spelling,
which would make OP's argument stronger. The very argument you disagree with.

Truth is, you first learn the basics of speech communication. You understand
sounds come from your mouth and given a specific cadence and tone you can form
words to get what you want. This is no different than understanding the basic
principals of computer programming. Principals all computer languages use.
Specifics of the language (syntax, grammar, spelling) is something that can be
mastered later, but without the principals, you're not going to master
anything. This is a major reason why there are so many bad PHP examples out
there. People don't learn to program, they learn to write PHP code poorly.

~~~
zecho
I find both of these analogies inadequate.

Spend more time around young children. They most definitely do not learn
grammar before they can communicate. It is not a linear thing at all. People
pick up parts of grammar like the Subject Verb Object syntax _as they learn_
to mimmic diction and build vocabulary. They're constantly "wrong" and need to
be corrected. With persistence and practice and, most importantly, interest,
we acquire taste and style.

Communication is very much a trial and error kind of learning that is holistic
rather than linear. "Learn x, then do y" versus "do y, then learn x" is a
false dichotomy.

------
crisnoble
Best quote in the article:

    
    
        There are so many benefits to jumping right in. 
        You’ll quickly get over any fear you may have of programming. 
        You’ll start seeing the fruits of your labor right away.

~~~
deveac
This did it for me. I've been having this _exact_ same thought for the past
two weeks. After hitting development bottlenecks on my last project, I
committed to learning to code to the point where I could hack together
functional prototypes. I've been training by manual, and was just speaking
with a friend about how dry it is and the fact that I'd be more fulfilled
working on a project and couldn't wait for that.

We have an extremely small, simple project that we've been talking about.
Screw it. I'm dumping the book and starting on _that_ as soon as I get home.

Exactly what I needed to read.

~~~
crisnoble
Awesome! I have been trying the same sort of thing and documenting it here:
<http://mksht.crisnoble.com>

I was inspired by: <http://mroosendaal.prosite.com/628/612/work/msced> and
<http://designitcodeit.com/>

Plus Mig Reyes's quote "Just make a bunch of shit" or the more eloquent way
that Ira Glass put it "the most important thing you can do is do a lot of
work. Put yourself on a deadline so that every week you will finish one story.
It is only by going through a volume of work that you will close that gap, and
your work will be as good as your ambitions."

~~~
deveac
It is funny. I was talking to a kid that was learning to play guitar because
he wanted to play cover songs, and was frustrated by the lessons that seemed
to have nothing to do with what he wanted. I told him that he didn't have to
wait even one more day, since playing covers songs is one of the best ways _in
which you learn guitar_. His ultimate goal could be accomplished almost
immediately by choosing one song he liked that only had 3 chords, and just
strumming those three cords over and over again in succession until it didn't
sound half bad. Would take less than a week, -tops.

It's the same principle, and one I value highly. I think tackling a new
discipline, and the wave of information that rushes toward you as you put your
toe in the water can sometimes distract us from simple grounded approaches
that we know have worked well for us in the past.

Thank you for the links!

~~~
andrewflnr
I learned piano in a similar way. It was a lot of fun, and allows me to play
some songs passably, but I still feel hobbled by not knowing certain basic
techniques that I would have learned sooner in a more conventional set of
lessons. Maybe it comes after the "project" type learning, but at some point,
to move up, you have to learn the boring basics.

~~~
suneel0101
Agreed! I'm also a pianist, but because I started young, I was lucky that my
parents and teacher forced to me practice technique all the time. You should
check out the Liszt exercises, they will make you strong and fast:
[http://books.google.com/books/about/Liszt_Technical_Exercise...](http://books.google.com/books/about/Liszt_Technical_Exercises_Complete.html?id=A4OVdTt3UMsC)

With coding, there was no such outside pressure, so until I joined Yipit, I
had tons of bad, hacky habits. In order to get to the next level, I had to
rebuild from the ground up and learn the fundamentals really well.

------
estebank
I disagree slightly, as I don't think that following that path of reading
instead of jumping in is inherently worse.

Just jumping into writing code is great for motivational reasons because
you'll have something tangible, something to be proud about and to help you
get excited and keep learning. But you'll still lack insight in a lot of the
surrounding environment, things that any programmer should know.

Attempting to do this the other way, reading as much as possible and as in
depth as possible, will be good to give you some insight, but you'll have
nothing to show for it until you start coding and it'll still take time for
you to learn some stuff that can only really be understood with practice.

What I'm trying to get at is that it doesn't really matter how you start, as
you are going to have to dedicate 10,000 hours to learn, polish and excel at
_any_ craft.

------
elchief
Well, you need to know what is out there, and what is possible. So at least
skim over some of the technologies. You could waste a lot of time if you
didn't know say, Sass, existed.

There's also a timing problem. If you invest now, and learn technology T, then
when you are in the middle of developing a project, the marginal cost of using
T is very low. But if you are up to your neck in a project, and then need to
take a week off to learn T, you are not likely to do so.

Personally, when re-starting my tech career I wish I had learned Java (or any
JVM language) over PHP, PostgreSQL over MySQL, and Dojo over JQuery.

------
bradddd
Great insight. Every time someone says, "I want to learn to code." They should
have a project/task in mind and just go. The stack that Suneel lays out is a
good foundation for web dev, but as he admits, he like many others invested
more time than was necessary in books/documentation/tutorials.

More people need to just jump in. If you get to a point that you want a
feature from jQuery, look it up and implement it, but don't feel like you need
to wrap your mind around every feature before you can begin. Great work and
keep at it.

~~~
drcube
>Every time someone says, "I want to learn to code." They should have a
project/task in mind and just go.

If there was a list of software projects somewhere, ordered by difficulty,
with tips on how to get started and how to extend it later, I would be very
interested.

I can code (somewhat), but I find that any time I have an itch to scratch,
it's much easier to google it and solve it through existing software and
configuration changes. Every time I've had a project in mind, I'm quickly in
over my head. I'd like to move beyond scripting and actually build self
contained software I can post on Github and give to my friends, but I guess I
don't know where is a reasonable place to start.

~~~
manaskarekar
<http://mindprod.com/project/projects.html>

~~~
bradddd
That's a nice list to help people when brainstorming. I wasn't necessarily
implying that the project had to be something new or different, or even
specific to the user. A lot of people learn rails or django by making some
microblogging twitter clone. On a recent relevant topic, sometimes the best
ideas come from emulation and slight modification, so maybe you just challenge
yourself to replicate a site or web app you use.

------
SatvikBeri
I've had a completely different experience. The first few times I tried to
write code, I learned only what I needed to know for the specific app. I hated
it. It seemed like I was just learning a bunch of random syntax and beating
them into shape.

Later, I actually tried the textbook first approach, and this worked much
better for me. By learning the framework and being able to observe the
patterns, learning new commands was much easier and I could often guess at
exactly what I'd need to do. I also remembered commands for much longer than I
did with the first approach.

YMMV, but some people have more theory-centric learning styles and some have
more application-centric. Test and figure out what works for you.

------
burntwater
I wonder if the advent of web programming makes this process all the more
confusing?

When I took basic Java and VB programming courses in college 10 years ago, we
focused only on Java and VB. There was no HTML, CSS, JS, frameworks, etc. And
you could have a complete, functioning program with GUI from the start.

Now, to create a web app, you have to learn all those other things _in
addition_ to Ruby, or Python, or PHP. As you advance in skills you'll likely
move to either front-end or back-end, but when you start out creating
everything from scratch, it feels like there's so much more.

(This coming from someone who did IT work for the 10 years following college,
and is not trying to break into the web developing world).

------
russell
Ask a developer who is working in the area that you are interested in to give
you some guidance. My girlfriend decided to become a web designer. Do she
asked an experienced developer, me. I said HTML, CSS, JavaScript and JQuery.
She added Photoshop and some image creation tools. She learned the parts I
suggested and decided to go to a community college to get some focus.
(Actually, she originally signed up to get the student discounts on the
software.) In a few months she will get a job to get some practical
experience. Then she will tackle her own projects.

------
baseh
This pretty much applies for any endeavor ; not just learning to code. Thanks
for the post.

2 Biggest mistakes when learning to [TASK X]

Mistake #1: I spent too much time learning things that I didn’t actually need.

Mistake #2: I didn’t start [TASK X] right away.

------
njharman
YMMV But I typically do #1 when learning / starting anything I don't know
about. That is I some proportional amount of time googling/wiki
reading/pinging friends for all the info/standards/tools/libs around subject.
Review* them for worth, spend more time with ones that pass.

It is very helpful to have a idea of the breadth of and resource for a
subject.

Review typically means "experimental coding". The 2nd point "start coding now"
is a Truism. Just don't start coding "production". Learn some, think, first.

------
sunraa
As much it pains me to admit it, Nikes' "Just Do It" applies here (and in
life) as the author has learned. The procrastination and anxiety that comes
with tackling something new can be overwhelming. The task oriented approach
narrows focus and makes you think about what you need to learn. Fear is also a
great motivator especially when your lead is breathing down your neck with a
'JGID - just get it done' attitude. :)

------
dwoot
suneel, many people make this mistake. I went almost EXACTLY the same route
you did. Although, I had already known HTML, CSS, and some Javascript, I was
wildly unprepared for what I would encounter next just to learn how to get a
working prototype. It basically took me 8 months before I got something
running on Heroku. I went through four different Django books with some
success here and there, including the Django Project's simple Poll tutorial
three times without grasping it. Little to my understanding, all of it made
sense once I used the book written by one of the creators of Django himself. I
also used a lot of StackOverflow and the guys hanging out in #Python and
#Django Freenode IRC channels were awesome!!!

The trial and error got me to learn a lot of things. In addition to the six
things that you've listed, I forced myself to learn VIM as well. You probably
use VirtualEnv, which you've forgotten to list.

Anyway, it's always good to see others going down the same road and sharing
their experiences. Do you have some links to some of your early projects?

------
henryxie
Totally agree. Prototyping is all you need to test out a startup idea. And if
you learn by doing, everything you learn is useful!

------
tedmiston
It's easy to worry about every details and learn every piece of tech yourself
all at once, but it's a recipe for unstable foundations and disasters of
distraction.

Creating small achievements by prototyping simple ideas in unfamiliar
technologies gives me small, concrete rewards to celebrate the journey.

------
GrueFiend
Knuth hath said: "A person who is more than casually interested in computers
should be well schooled in machine language, since it is a fundamental part of
a computer."

I agree with that sentiment. The whole "focus on what works" is not the same
thing as "understanding what the hell you're doing."

------
logn
I think you can reduce the list a lot more--and should. I'd choose a single
language and learn it well and go from there. And I'd only work the command
line features. So Ruby on the command line or JS or Java would be my choices
(but only one).

------
mikeryan
This is actually just 1 mistake.

Start writing code, make it do what you need it to do today. This will focus
your efforts to what you need to do at the present moment and you won't end up
trying to figure out how to deploy an app you haven't built yet.

------
MojoJolo
They say you learn best through experience.

I learned CakePHP by coding my thesis with it. Now, I wanted to learn python +
postgres by planning to port my thesis to it.

~~~
fourstar
Why would you want to switch to Postgres out of curiosity? Also, what MVC
framework are you switching to?

~~~
MojoJolo
I used MySQL and I'm trying Postgres out of curiosity too. Django is the MVC
framework that I will use. :)

------
mikecane
Everyone out there who wants to learn to code, stop reading these comments and
use the time to just go learn!

------
webjunkie
Yeah, away with all that crap, just use Django already! Good decision.

~~~
c-oreills
I'd be wary of recommending Django to a beginner, unless their project
definitely required it.

Flask is lightweight, simple, and you can understand most of it in a very
short period of time. I'd say it taught you to code more, whereas Django
teaches you to use Django.

~~~
olifante
Better yet, use Express and focus on mastering one single language for the
client-side and the server-side: either JavaScript or CoffeeScript.

------
waynengai8
keep blogging suneel....maybe this will finally get me to start learning!

------
lhnn
To Generalize (for web):

HTML/CSS/JS (View)

jQuery (View Framework, couldhave been YUI, for example)

Programming language

Framework in said language

I still think actual SQL / DB knowledge is requisite to do all but the most
minor of apps, but he is specifically trying to get people from being
overwhelmed.

I'm struggling with Play!, because I need to know HTML/CSS/Java/Scala subset
(templates)/EBean ORM/the massive library that is Play.

Just a simple app touches on so many libraries and helper functions, it's hard
to get a grasp of what's going on. I don't even build a form anymore, I build
a form-ish object that I pass to the controller that fills in data to the ORM
that inserts stuff into the database. o_O

------
goggles99
You put the cart before the horse (which was actually your first mistake).
When you get out of college - get a job, work a while - then start a side
business. Your startup success odds will more than quadruple following this
advice.

