Hacker News Reader

In my opinion, compiler implementation is such a path. You can touch almost every aspect of a modern system, and many well trodden areas of Computer Science:

1. Lexing - DFA's and NFA's, hand coded or with a lexer generator, relationship with regexes

2. Parsing - LL, LR, table driven, recursive descent, hand coded, parser generator generated

3. Interpretation - simulate control flow and data representation in a host language

4. Translation - generate bytecode for an existing vm like JVM or CLR, or assembler for processor architecture of your choice

5. VM - implement you're own vm, choose an instruction set, implement garbage collection

Getting a handle on this set of knowledge and skills will take you a considerable way to becoming a 'master'.

"The more I "level up" in development, the more I'm convinced there is not enough attention paid to how to really advance through those levels."

This for me is the major takeaway from the article. Trying to learn material 2 levels up is unhelpful. It's especially bad since most of us are used to formal schooling where level progression is determined for you

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.

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.

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.

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

I see this personally particularly when giving talks. Many early academics / PhD students try to go straight to the "Steve Jobs" style of talking, trying to explain things with no (or very minimal slides).

I'm increasingly sure you simply can't go straight from nothing to no slides, and trying to force it will just cause you and your audience pain. In particular, only by giving a number of talks do you learn what the 3 things are you HAVE to have on your slides -- just being minimal for minimal's sake isn't useful.

"They see their relative place, and can aspire for levels greater, which before would never have occurred to them even existed."

Note this applies to UI design. A bad UI makes it impossible for the end users to "level up".

Typical example: Start with the corporate standard database system, Excel. You end up with secretaries doing the equivalent of a simple SQL "JOIN" by hand. Hopefully using copy-paste instead of hand typing. Sadly I only dream I was kidding. On the bright side technology has improved as in 2013 we use Excel for this task but in 1996 I worked at a big iron financial services corp where the master customer database was a word processor file.

> You end up with secretaries doing the equivalent of a simple SQL "JOIN" by hand.

Before Excel, they wouldn't be doing it all. Baby steps.

Spreadsheets as a paradigm is HUGELY successful at allowing normal people to do number crunching—number crunching that pre-spreadsheets would have required a programmer, and most likely, would never have been done at all. I think that's a win, even though we can (and hopefully will) go beyond that over time.

Sure they did. That was my point, in '96 the master customer list was a word processing file. They use a spreadsheet now because mere mortals can't figure out columns in Word.

Ah, I misunderstood.

> Before Excel, they wouldn't be doing it all. Baby steps. ... Spreadsheets as a paradigm is HUGELY successful at allowing normal people to do number crunching

Spreadsheets were a thing before they were put into computers, you know...

http://en.wikipedia.org/wiki/Spreadsheet

> The word "spreadsheet" came from "spread" in its sense of a newspaper or magazine item (text and/or graphics) that covers two facing pages, extending across the center fold and treating the two pages as one large one. The compound word "spread-sheet" came to mean the format used to present book-keeping ledgers—with columns for categories of expenditures across the top, invoices listed down the left margin, and the amount of each payment in the cell where its row and column intersect—which were, traditionally, a "spread" across facing pages of a bound ledger (book for keeping accounting records) or on oversized sheets of paper (termed "analysis paper") ruled into rows and columns in that format and approximately twice as wide as ordinary paper.

Spreadsheet applications made book keeping jobs much easier, to the point that book keeping (not programmer) is on the outs as a speciality job.