Hacker News new | ask | show | jobs
by thesmallestcat 3048 days ago
> Traditionally, there are two ways to study a page like this:

> 1. Type out every line of code

> 2. Copy+paste the code from their website, maybe play around and make small changes

Um... wut? How about:

3. Read the code. Think.

If you're reading programming books as practice, and think you're supposed to copy the code examples to learn, you're doing it wrong. If you need eval() to figure out what's going on, you need to spend more time practicing the basics, then step up to the book.
2 comments
d0m 3048 days ago
Yeah, I've never typed any of the code examples of programming books.. I just read it to understand the concepts. Often I can go really fast when most of it is familiar, but when something catch my attention I work hard to decipher and understand it. if I can't, I'll re-read the chapter or search online.

As a side note, it would be great to have more programming books written like this. I.e. We assume you already know language X so here are the differences and why; focusing mainly on specific code examples and gotchas of the new language.

I would prefer semi-pseudocode:

    import { drawDragon } from 'drawing'
    <other imports..>

    function(screen) {
      screen.render(drawDragon.new('red'))
    }
By semi-pseudocode, I mean that I'm okay with not having the program in its full completeness with the less important part being abstracted away, but for the concepts that are being explained to be detailed, thorough and well documented.

As a fun exercise, one could take a big programming book and trim it down to a 1/10th (or more). There are so many useless sections. Most great devs are good at skipping through the bullshit.. why not just remove that part entirely!

Reason is probably monetary or politic. I.e. can sell to a larger audience by being more beginner friendly and/or need to have a certain amount of page and follow a template to be published.

link
rootlocus 3048 days ago
> 3. Read the code. Think.

While this is definitely what I do, for some reason, I always believe I'm not doing things "they way you're supposed to", so I almost never argue when articles don't mention doing things the way I'm doing them.

link