11–20 of 29 posts
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 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…
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_.
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 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.
Earlier quoted context omitted.
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!
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!
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 t…
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.
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.