Ask HN: Why do I find it so difficult to learn to code?
17 comments
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.
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.
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.
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!
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!
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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!
Why do you want to learn to code so badly?
Not everyone can explain their yearnings. Some want to fly planes, or play guitar, or climb mountains. It's just innate.
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!
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?
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_.
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.
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
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.
----
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.
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.
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.
Lots of great advice in this awesome article by AI guru Peter Norvig
http://norvig.com/21-days.html
http://norvig.com/21-days.html
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
also, some great advice by Zed A. Shaw
http://learnpythonthehardway.org/book/advice.html
http://learnpythonthehardway.org/book/advice.html
Can somebody PLEASE help me overcome this problem as I want to code more than anything.
Thanks