Ask HN: Why do I find it so difficult to learn to 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.

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'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.

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.

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'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.

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!

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!

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.

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.

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.

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

----

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.

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.

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