

Ask HN: Why do I find it so difficult to learn to code? - Spock

I have been trying to learn how to code using numerous languages for the past 10 years.  I go over the same stuff, strings, variables, arrays etc and I possibly get about 100 pages through a book, everything feels great, I'm understanding what I read and I do the examples.  For some reason, out of the blue I hit a brick wall and suddenly I feel overwhelmed and stressed, I look at other people's code and it's as if I'm reading Chinese.  I get dishearted and eventually stop.  After a few weeks/months I repeat the entire process.  I've used several languages over the years so I know it's not the language.  Is it something I'm destined not to do or could I be doing something wrong?<p>Can somebody PLEASE help me overcome this problem as I want to code more than anything.<p>Thanks
======
rprospero
Here's a slightly different piece of advice.

When you get in 100 pages, around the point where you start getting lost and
frustrated, stop reading and write some simple programs. Don't do the large
projects everyone else is suggesting. Just some simple project euler programs
or programming praxis. Writing a program that plays poker is always a good
test project, if you can't think of anything.

The reason for doing this is that, for most languages, everything that you
want to write can be written with what you learned in the first hundred pages.
You'll know how to declare a variable, write a function, and implement flow
control. You don't need to know more.

However, the code you're going to write will be really crappy. That's the
point. If you're like me, that part of the book where you're getting stuck is
when they start introducing language features to solve problems that you've
never had. For instance, like many people first learning Haskell, I kept
getting stuck on Monads. I eventually gave up and just started trying to write
Haskell without them. I could write code, but certain sections were very
tedious and ugly. I got tired of writing the same ugly boilerplate over and
over again and checked the documentation to see if there was anything to help.
Lo and behold, monads eliminated that boilerplate and I could now understand
where the author was coming from.

I'm guessing that, depending on what language you're studying, you're getting
lost somewhere around classes, macros, monads, or namespaces. Whatever it is,
just write some code without it. I'd argue against picking a big project for
yourself, since you'll be subconsciously guided by what you know how to
implement. Instead, take a small list of test projects and complete several of
them. This lets you learn the language well enough to find the ugly points.
Then go back to reading and I bet the advanced capabilities, which remove
those ugly bits, will make much more sense.

~~~
Spock
This is fantastic advice, I have tried Euler in the past and struggled on the
first question haha. I think when things pick-up from the basics of variables,
classes, objects etc, that's where I start going wrong. I know about the
mechanics of programming, it's using the tools to solve problems is where I go
wrong.

------
helen842000
It sounds counter intuitive but don't look at other people's code (yet). It's
kinda the equivalent of being in a race, feeling like you're doing well,
looking up and seeing those runners miles out in front, feeling panic which
causes you to stumble and give up.

Don't do the comparing thing, it only hurts your feelings. Like a pianist
diligently practising scales only to give up when they hear Chopin.

I was stuck in the same cycle for a long while re-learning the same things
every night. My best pieces of advice would be:-

1)Build increasingly bigger projects that work, are useful and go in some kind
of portfolio - this demonstrates your progress when you feel overwhelmed. Much
better than churning through a pile of tutorials and exercises.

2)Try tutorials that force independent problem solving - Like Udacity.com.
More "find a way to", less "type this out"

3)Get good at noticing when & why you are stuck. Write down things you hear
that don't make sense and look them up, ask online/forums etc. Write down what
you tried. You can still make progress when stuck. If you're working on a
project and you hit a wall - your job is to stop coding and research.

The fact that you keep trying says you're obviously willing to stick at it!

~~~
billswift
A couple of additional points:

Reading other people's programs doesn't help much because, unless you can find
some really small standalone programs, they are going to be too complex for a
beginner to learn much from.

Explore variations on the small programs presented in tutorials, try changing
things - then try them out to see whether they now work as you expected, if
they don't, _keep at it_ until they do. It is never to early to start learning
debugging.

------
breckinloggins
Let's talk about Chinese.

Can you "learn" Mandarin by reading a few books on Mandarin, taking a few
courses, attempting to read some books in Mandarin, and occasionally speaking
a few words to that cute Chinese girl at work?

Yes, you can "learn" Mandarin that way, but you can't Learn it.

If you were REALLY passionate about learning Mandarin, you would have to go to
China (or at least Chinatown) and stay a while. Then you would be driven to
learn Mandarin because you would need huge chunks of it for very real things.
NOT learning Mandarin would be more painful than learning it.

You need a project. You need a project complex enough that you need huge
chunks of programming knowledge to implement functionality. You need a project
so interesting to you that it's more painful NOT to learn how to program than
it would be to learn.

UPDATE: One other thing. It's ALWAYS difficult to read other people's code.
Always. This gets easier, but complex codebases always look like gobbledygook
the first time you look at it. I've been programming for 20 years and this
still happens to me. You get used to it. What's the strategy? How do you eat
an elephant?

~~~
Spock
I realize that you cannot learn Mandarin over night, as with programming.
However, surely after 10 years worth of basics, I should have progressed
further than I have.

------
ajuc
I don't know, I can only tell you what worked for me. It was "just doing it",
without worying about style, guidelines, whether this will scale, is this the
best practice, I just wanted to do something, I wrote the code that was the
least resistance path to achieve it (I wrote 5x5 word guessing game in
TurboBasic - I didn't knew how procedures worked, I did not knew that there
was while loop, so i wrote one for nested into other for with the bigges
numbers I could put there and worked, it was basically one big loop with if
for each case, and a few variables. I should be ashamed of this code, but I
was proud, because it worked. It was magic. I've shown it to my friends and
parents, and everybody, and I felt so great.

I've tried something harder next time. And I've found about arrays - so I
don't have to name my variables X1, x2, x3, x4 and check them with ifs, so I
used arrays, then I found out about procedures, etc, etc. Then I used that to
write next simple logic game, and so it went.

Whe you have something that works, it's easier to see why you need arrays, or
functions, or loop without counter :) And it gives you motivation.

Anyway - good luck.

------
pbreit
You need to spend less time _reading_ and more time _writing_. And ideally
that writing should be programming something useful, not just an exercise.

One of the best learning environments I've seen is the Python framework
Web2py. It was developed by a professor originally for teaching purposes.
Python is a nice clean language. You should be able to make some effective
progress in an afternoon.

------
lexalizer
Start without looking at other people's code. Think of simple projects you
could do, and do them from scratch. Even highly experienced contractors have a
difficult time going over other large projects if they are not familiar with
the code.

Don't try to make everything perfect from the first time. Make it work, then
you can improve it.

Build a simple tool first, such as a video converter or a timesheet management
tool or even the classic blog, calculator, image gallery etc.

You will hit not one, but many brick walls, you just need to know how to find
a way to go over them. If the problems you are trying to solve when you hit
the brick wall are too complex, divide them into smaller things you can tackle
independently.

While you are doing this, keep on reading about programming as well as
secondary processes that can make your life easier.

And finally, use an IDE, not notepad, learn to do TDD and how to use a
profiler. You'll save yourself a lot of time.

I hope this helps you.

------
jdietrich
You can't expect to read art books and study the grand masters and one day
magically be able to paint. You start with crayons in kindergarten and work
your way up to oil on canvas.

What you need to do is write code. Lots of code. Lots of badly broken, half-
functional code. The software equivalent of a child's doodles. After six
months you'll be writing code that kinda works some of the time, after two
years you'll be a reasonably competent developer, after a decade you'll be an
expert. But for any of that to happen, first you have to write a whole lot of
bad code.

~~~
Spock
That's just it! I understand that solution perfectly, it just doesn't seem to
sink in/work for me. I've been doing 10 years worth of basics and still can't
progress.

------
stonemetal
_I look at other people's code and it's as if I'm reading Chinese._

How large a program have you written on your own? Where are you finding code
to read?

I wouldn't start reading code until you are fairly comfortable writing and
debugging code. Reading code is harder than writing code. Start by trying to
read code you wrote but haven't looked at in a month. That way you are
familiar with what it is supposed to be doing and the style it is written in.

~~~
Spock
I suppose the largest things I've done is a meme website in PHP which displays
an image, forward and back, and a random button, and an upload script; all
integrated into MySQL. A football game in Pascal which uses 1 2 3 as user
input, and a goal keeper which generates 1 2 or 3, if the input is the same as
the goal keeper, then the ball is saved, else you score. And I did a text
based adventure game in Python.

------
astrodust
Maybe you're just not in the right mind-set. Programming, being highly
analytical, requires a certain outlook to properly understand and if you're
not in that state of mind you might have little luck getting anywhere.

I'd argue a good portion of learning how to program is simply in learning how
to hold yourself in that state for longer periods of time.

The best way to introduce yourself to programming is to start small, build
something, but always build it to _completion_. You learn very little from
efforts that don't produce results. Even a "Hello World!" success propels you
forward a tiny bit. Build on it. Make something incrementally more complicated
from there.

The best motivator is to have an idea that's compelling. Always start with
something _far_ simpler than your original idea, strip it down to the absolute
essentials, practice by building parts of it in isolation and later try for a
more integrated approach.

The other thing that's important is persistence. You need to put in a bit of
time each day, every day, in order to move ahead. Taking a few days off is
damaging to your momentum and in that time you're already losing track of
things. Training requires continuous exposure.

------
LarryMade
Don't look so critically at others code - everyone has their own style to
programming, you can do much the same stuff with complex code as with simple,
functional or object oriented. Glean what you can/want from it now and don't
fret over the rest, come back to it later as you improve.

If you have issues with your own code, work them out. One thing that helped me
deal at my code was to work on my formatting and readability. Breaking up long
lines consistent indenting, better variable, field and and function naming
etc.

Third, use some concept you 'own' to work on. As in a project of some sort, a
concept you understand forwards and backwards... maybe a baseball card
database, or an event calendar - maybe you nailed it years ago in language X,
do the same now in language Y. This is so you aren't fighting with deciding on
what you want, you just need to discover in the language how to get there or
how to improve upon what you know, also it will give you a quicker success in
the new language which is good for the ego too.

I think also the more experienced (older) we get the more frustrated we get
when things just don't just work the first time, so we need to fight that
frustration a bit more.

------
hnbd
If you want to code more than anything...find code you are passionate about.
Think of a small project you want to work on and learn what it takes as you go
along. Just reading text books won't really teach you how to program. Finding
something you are passionate about will allow you to fight through the
challenges you run through.

When I was in elementary/high school, I got into programming purely through an
interest in reverse engineering and writing hacks and bots for online games.
My interest in it allowed me to get through reading assembly and complex C++
memory injection code that was way beyond me at the time and learn from it.

Reading and understanding large code bases is not an easy thing. When I
started my first job at a very large enterprise software company working on a
20+ year old massive code base, I had some serious anxiety when I first looked
through the code. But take your time exploring it and trying to understand it,
look things up as you go along, and you will eventually start to understand
it.

Write some code with a purpose!

------
revorad
Why do you want to learn to code so badly?

~~~
astrodust
Not everyone can explain their yearnings. Some want to fly planes, or play
guitar, or climb mountains. It's just innate.

~~~
Spock
I agree with this. I cannot explain why I want to. It has something that I've
craved to do my entire life, I cannot put into words or explain why, the
hunger I feel to code. I feel very drawn to it and it is extremely appealing.
That is all I know!

~~~
revorad
That's very interesting. What specifically are you drawn to? Is it someone
else's code you saw or the feeling you got when you first automated something?
Or is it the theoretical aspects of computing?

------
dholowiski
Don't rule out ADD or Dyslexia (even at a low level) as limiting factors when
you're trying to learn something from a book or read other people's code. In
the last couple of years I've learned a lot about programming by just making
up some ridiculously large project, and _just doing it_.

~~~
Spock
I have always considered that when I hit this point of frustration that I'm
talking about. It feels like it's the only variable I've not taken into
account.

~~~
gtani
are you in a city with PHP/python /ruby usergroups/Meetups or hackerspaces or
maybe coffee shops where people hang out and code? It's hard to code for
extended periods in isolation

------
Spock
I found this poem which describes how my problem feels.

\----

I am like a toolbox, with all the tools I will ever need lain gently and
neatly in the box, ready for me to use them. The toolbox is translucent so I
can see them there.

The key to the toolbox is locked inside of it.

------
doug1001
one-line-at-a-time.

Just start typing at the interactive prompt (e.g., IDLE, included with
python); when you finish typing a line, press return and see if it executes.

If it doesn't then type it again until it does.

But just start typing. It's a _language_ you are learning--so start by
_speaking_ it.

repetition is the mother of skill.

All of the stuff in the books about _lexical dispatch_ , _aliasing_ , _Liskov
substitution principle_ , _guarded re-binding_ , _immutable namespaces_
\--screw that. You'll come back to that stuff when the time is right and by
then you will have already been doing all of those things.

Again: one line at a time. This will work, and you will have fun. i promise.

------
tuxguy
Lots of great advice in this awesome article by AI guru Peter Norvig

<http://norvig.com/21-days.html>

~~~
Spock
Haha yeah, I love that article, I've been reading it for the past couple of
years to motivate me, I've even got a print out! :D

------
tuxguy
also, some great advice by Zed A. Shaw

<http://learnpythonthehardway.org/book/advice.html>

