Comment by Dove | Hacker News Reader

Comment by Dove | Hacker News Reader

He is right that you want to study 'tactics' -- ways of making code good. More generally, methods of expression, their benefits and drawbacks.

He is wrong that you want to study it by critiquing code and devising your own improvements. This would be analagous to creating chess puzzles for yourself and then solving them -- it is a very slow way to discover things you don't know.

There's a whole world full of brilliant ideas out there; far more hacks than anyone has the insight to devise in a lifetime. Learning specific technologies is a necessary evil; read something like A Simple Guide to LaTeX if you think you'll need to use it in the near future. Otherwise ignore it. But read Programming Pearls to get better forever. Read some nice OSS code. Read a book that talks about, not how to use a particular language, but how to use a particular language well. Find some language smart people love, in a paradigm you don't understand, and really embrace what makes it expressive. Not by yourself; engage the community. Read their books. Read their code. These things quickly make you better forever.

Your point about studying code & improving it in isolation is good. The weakest part of the analogy, in my opinion, is that in tactical chess puzzles there's actually a right answer.

On the other hand, if you have a chess puzzle but not its answer, you can still practice recognizing the tactical situation (hung pieces, checks, forks, pins, etc.) That's closer to what I was suggesting, and I still think it's useful: learning the jargon first, and then reading code and taking the time to describe it in terms of that jargon. The purpose isn't to "discover things you don't know", it's to concretely drill and internalize things you do know.

Ah! Then I agree, practice is essential.

Sometimes you'll think something -- a particular brace style, a naming convention, a commenting convention, a design choice -- will make code better. But when you try it, it doesn't help comprehension or maintainence.

There is no substitute for honestly taking the time to make some code the best you know how, and then being stuck maintaining it for a fussy customer for several months. If you never had the time to do it right, you can deceive yourself about how good it might have been. But if you know you did your best, you have nothing to blame the inevitable mess on but your own abilities.

Reply on news.ycombinator.com