Hacker News Reader

Comment by schwurb | Hacker News Reader

Others gave good answers. I just want to emphasize that your progress will greatly depends on inter talent (which you can't influence), passion and discipline (which you can influence to a degree) and methodology (which you can influence even more).

View points on methodology: 1) Read more than you write. There is excellent code out there. By reading it, you learn to think like an experienced programmer. 2) Hands on > Books. The best approach is to pick an project and program away. Problems will arise naturally (How do I print something to the command line? How can I store data in a list? How can I search an element in a list? ...), which is the best time to look up the solution. 3) Mentors are invaluable. If you live in a big city, there will be programming meetups. If personal contact is not possible, try to see somebody online.

All the best!

View on HN

> 1) Read more than you write

It's important since most of your work related to code will be reading code rather than writing it.

> 1) Read more than you write.

I disagree. You should write as much code as possible, run into as many problems as possible, and solve them. This is how you actually learn how to program. Feel free to play with and adapt other people's code along the way though.

> There is excellent code out there.

Sure, there may be "excellent code" out there by some standard, but nobody can agree on what "good code" is. Your application of "clean code" and "design patterns" might be considered overengineered enterprise junk. Your side-effect-free generalized functional code might be considered obtuse and academic. Your straight-and-to-the-point procedural code might be considered inelegant or "not modular enough". People have way too many strong opinions on this subject and they can't all be taken seriously.

Also, a lot of "excellent code" out there is written in older language versions, full of workarounds for problems that don't exist anymore. This is particularly important for Javascript or C++. The difference is is like night and day.

> You should write as much code as possible, run into as many problems as possible, and solve them. This is how you actually learn how to program. Feel free to play with and adapt other people's code along the way though.

Agree, but as much as possible should be limited by reading other code. If one spends 95% living in his own bubble, he will likely progress slower.

> Sure, there may be "excellent code" out there by some standard, but nobody can agree on what "good code" is.

The exact semantics of "excellent code" don't matter here. For all practical purposes, "excellent code" is what a "hey I am a python beginner please tell me your three favourite codebase to learn from thank you" thread on reddit yields.

On the other hand, it is stupid to ignore advice by experts. It is also stupid to not become able to recognize experts. This is a very important step in becoming good in any field - recognizing people who are better than oneself.

> If one spends 95% living in his own bubble, he will likely progress slower.

That's not going to happen in the age of Google. My point is, don't just read code. You have to write your own bad code to actually build understanding. There are no shortcuts.

> On the other hand, it is stupid to ignore advice by experts.

When it comes to programming, it's stupid not to ignore advice by so-called experts, because a lot of it is mutually exclusive.

You need to be able to understand where an expert comes from and how to apply their advice to specific problems. Otherwise, you end up with cargo-cult programming.

This is not what you want to deal with at the beginner stage. In that stage, you want to train your brain to be able to program, not to deal with all the expert mumbojumbo. That's why it's better to start with BASIC (or Python, these days) than Java.

> It is also stupid to not become able to recognize experts.

No, that's actually the default state of being. In order to tell an expert from a snake oil salesman, you need to be an expert yourself.

> This is a very important step in becoming good in any field - recognizing people who are better than oneself.

Everyone is better than you at the beginning. That doesn't mean you should take advice from everyone.

> Building stuff

Oh, absolutely one should build much stuff. Just don't get stuck in the own, in all likelyhood shitty, bubble.

> Experts

You made it sound fatalistic tho, as there were no use in even trying to identify experts. If you have difficulties telling experts from wanna-be experts, that is your problem, not the problem of beginners.

You also don't have to be an expert to recognize an expert. The level of competence needed is way lower than that. The level of social skills needed to recognize the different schools and camps is high tho. But this is rather a social problem than a domain-specific one.

> You made it sound fatalistic tho, as there were no use in even trying to identify experts.

No, that's not what I mean. Identifying experts is one thing. It's pretty easy to tell if someone is recognized as an expert by others.

I'm talking about appropriately evaluating and applying that expert advice. You need to be an expert yourself to actually do this, and it's not what beginners should concern themselves with.

> You also don't have to be an expert to recognize an expert.

You have to be an expert to evaluate other experts and their opinions.

Reply on news.ycombinator.com