

Review HN: my first essay "Thoughts on learning and programming for Hackers" - SingAlong
https://docs0.google.com/a/akash.im/document/edit?id=1uJbohrZAKGVGxrJv-d443kW4xFnf7YWgj40yd942iMI&hl=en&authkey=CPqywNQF#

======
RiderOfGiraffes
OK, it's not clear how detailed you want a critique to be, so I'll throw out a
few thoughts that I hope you find useful, interesting or provocative.

Firstly, let me say that I'm always humbled by someone who writes clearly in a
language other than a cradle language. Having said that there are many, many
small grammatical errors. Even so, the writing is pretty clear, and most of
the errors do not obscure the meaning. That's impressive.

You say:

    
    
        A similar approach, learning only when required, is
        good for hackers.  According to me, learning what's
        necessary when a situation calls for it triumphs over
        that of learning just because something exists or is
        available. ... I advocate learning as a process that
        is supposed to run in parallel with implementation.
        You learn by doing it and you learn only because you
        require it.
    

I think this is thoroughly, fundamentally wrong. Dangerously wrong. I think
you should have a voracious appetite for knowledge and information that
currently lies just out of reach, even if it serves no useful purpose. Time
and time again I've found that things I learned simply because they were
interesting have turned out to be crucial in understanding something critical
later on.

You can never know in advance what you will need, and chance favors the
prepared mind. The legendary golfer Gary Player said "The more I practise the
luckier I get."

Learn stuff beyond what you think you need.

Several times you say "Most engineers ..." and then say something that is, in
my mind, completely at odds with the majority of engineers I know. It started
to annoy me, and made me start to doubt other things you were saying.
Specifically, for example, I don't know any good engineers who think "writing
good code means saving every possible byte of memory and computational power."
You seem simply to be setting up straw men to be knocked down, and that's not
a convincing style. Your points should stand on their own.

There are several other points with which I disagree, but they're your
opinions, and I won't argue them here.

There are grammatical errors such as this:

    
    
        "They might be simple like a software that solves ..."
    

The "a" is unnecessary (and incorrect).

There are many other places where you have unnecessary words and the writing
could be tightened significantly.

And it feels like it rambles. It's not really clear what your main point is,
or how you're getting there. You have a lot of opinions that you state, and
clearly feel are self-evident, but there's not much of a logical progression.

But finally, and this is my main point, I read it to the end and was
interested. If this is your first essay, it will be interesting to see your
fiftieth.

Or even your tenth.

~~~
kanak
> You can never know in advance what you will need, and chance favors the
> prepared mind.

I agree with you fully. It's surprising how useful things from unrelated
fields can be. Just as an example, taking a course on economics taught me
about utility functions, and decision theory. The decision theory stuff became
really useful when I started learning Machine Learning; for example picking
from a set of competing models using decision theory to think about the costs
and benefits.

