Hacker News Reader

Comment by inetsee | Hacker News Reader

This is one of the fundamental ideas behind deliberate practice. You need to work right at the edge of your experience level. If you continue to work well inside your comfort level, you won't push your expertise out into new areas. If you try to move too far outside your expertise too fast, you won't have the foundation to support yourself; you'll flounder and get discouraged.

View on HN

I've been constantly looking for that progression. I'm a very poor programmer, but I would love to get better. I know C, C++, C#, Python, Java, Bash, and Lua all at a basic level just from having been introduced to them in classes or at work, but I've never found a good path to take one of them and become good at it. I've tried books and tutorials, but I can't find a progression of "Read this book, then this book, then this book, then watch this Youtube series." I can't figure out how to actually write programs once I've finished the first class, the first book, the first tutorial. I feel like the second book that people recommend to me is always two levels above me and makes no sense at all. Especially when people recommend the programming practice sites where the problems are all about solving math puzzles. I'm not that good at math, either.

I really wish that every profession came with a tutorial (outside of a four-year college program) saying "here's exactly what you need to learn, in exact order, to get started."

You are taking a sort of a bottom up approach of learning the languages. It's sort of similar to learning Japanese for the sake of it (which is fine). Language is for communication and of course programming languages are to make things with them. You'll find the process more enjoyable and easier to learn if you learn it with the goal of doing something with it, not just being good at it in general. If you need to make something and you can identify what you need to do to get there, you can start chipping away at the requirements and get closer to your goal, making the whole journey more exciting.

Ideally you would approach this from both ends. On one end you are learning bottom up. On the other end you see what you need to make and you backtrack from there until something you know and you try to make your way up.

Completely anecdotal, YMMV.

I've found I don't really level up by reading books or tutorials.

I level up when I actually do a project by myself from start to end. For the projects I do, there tend to be parts I know and parts I don't, so I still Google for the relevant bits and pieces that I don't understand.

So I guess keep working on projects that have parts you don't understand. There also need to be parts that you do understand, so that you don't feel like you're jumping in at the deep end.

On a side note, I'm not knocking reading books. They help me become aware of certain ideas, but I don't learn them completely until I've implemented it myself.

Niels Henrik Abel, when asked how he so quickly became proficient in mathematics said that he accomplished it "by studying the masters, not their pupils." I've learned languages by reading the writings of the author(s) of a language. Reading books is good, reading papers is even better. I didn't have a good foundational understanding of Lisp until I read McCarthy's paper on it.

I second the practical approach of working on projects. I've learned so much just by trying to do things I wanted to do, but didn't know how to do at the time.

I agree - I've read a ton of books, but usually only take small nuggets of knowledge from them and end up having to reread them every few years. Instead, most of what I know about programming I gained by doing. Writing a lot of code levels you up, not reading about writing code.

I find reading books, articles, tutorials is a great way of finding out what you don't know and what you might want to try tinkering with next to level up, because otherwise you just use the same techniques over and over, but to actually level up you need to get down and dirty and write a lot of code.

I used to get little value out of books, then I started reading better books. Check out this Amazon list for some high quality books. Don't let the "Clojure" theme scare you, these will make you a better programmer in any language.

http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH

Don't let the "Clojure" theme scare you

Actually, I use Clojure quite a bit, so that won't scare me at all!

I've already got Programming Clojure (and The Joy of Clojure - not on the list), Structure & Interpretation of Computer Programs and Concepts, Techniques and Models of Computer Programming. Purely Functional Data Structures and How to Solve it have been on my list for a long time too. Some other books that I haven't heard of before on that list look very interesting though!

I didn't really mean that I don't get value from books - I do - just that I find books to be only the first stage of learning and most useful in telling me what it is I don't know, which I then can study and try for myself and its the experimentation and tinkering that actually makes it sink in.

I've been in the same boat and I've discovered that the way to get better at programming is to get better at computer science. Most books on programming usually contain a lot of basic knowledge about language constructs. It's all variables, functions, classes, and then maybe some things about web programming. For the most part language constructs usually aren't enough to solve problems. It's very hard to take that knowledge and apply it to a fundamentally different problem than what was worked out in the book. And because the problems the book worked on were most likely trivial, you don't really gain much perspective on how you would build something more complex.

That's where computer science comes in. CS deals mostly with abstract concepts -- algorithms, data structures, parsing...that type of stuff. If you train your mind to think in these terms, then you start seeing programs as the sum of their parts (state machines, stacks, trees, grammars) and complex programs become less of a black-box. In effect you're transforming And because you can now picture how someone else has built their program, you just put those same pieces together and with a bit of thinking and googling, you can glue them up into something similar. Eventually you'll be able to picture your own solutions from scratch.

The thing, though, is that computer science is math. A different type of math, but math all the same. It's something you have to work at your own pace, patiently. Deliberate practice is not just a catchy phrasing. It's a very important concept. I stress this because I made the mistake of rushing through a lot of this stuff. I only half got it, but it's worth taking the time to fully understand even seemingly simple concepts because it opens up so many possibilities!

So in order to solve your tutorial problem ("what you need to learn, in what order, to get started"), I would suggest you pick a problem that's interesting to you, find out what sorts of concepts it depends on (what data structures are involved, what fundamental algorithms, ... that sort of thing) and work your way from those concepts to the solution (a working program). For example, if you were interested in building databases, you might want to learn more about b-trees, but in order to learn about b-trees you might need background in simpler data structures and work your way up. You might also want to learn about how to build a query engine, so you might want to learn more about lexing, parsing, and all that. From there you just learn how to implement those things (or find a decent library) in your language of choice and go from there.

Reply on news.ycombinator.com