Ask HN: Tips to become a great programmer

I was having a similar discussion with a friend of mine.

When I was a teenager, I wrote small C projects, then I discovered the world of OS development and set myself to write a minimal operating system from scratch. It was an amazing experience, with a lot of head-scratching, hours spent debugging weird hardware issues, reading other people's code and just churning out badly engineered (but working) code.

Now, 10 years after, after playing with Haskell, OCaml, Scheme, learning about best practices, variants, typeclasses, static vs dynamic typing and data structures, every time I set myself to write something more than 100 lines I just get stuck: which language is best for the job? How should I refactor this to be more clear and concise?

My programming life definitely got worse (as a C/Python programmer) after I discovered variants and the Option/Either monads.

As I said to him, ignorance is bliss.

You've taken the most IMPORTANT step already - You care about programming. Keep this up. Join forums, read books on programming, follow programming blogs.

Next, do not fixate on languages and frameworks. Aspire to make this irrelevant to you. Great developers often can work with multiple languages and frameworks.

Be prepared and excited to learn every single day of your life as a programmer. The best programmers I know are always learning. This is an investment you will need to make regardless of work pressures and schedules. I've seen far too many developers have their skills atrophy because they've not invested in improving.

Use the Rubber Duck debugging model - http://en.wikipedia.org/wiki/Rubber_duck_debugging.

One simple way to do this is that whenever you get stuck, go to stackoverflow and start explaining the problem.

I have found my solution innumerable number of times by forcing myself to explain it to someone else with no context. It makes you confront your assumptions and understanding.

Focus helps, of course. But my list (and other reading material..yes, it was abbreviated) was actually pretty focused - it specializes in programming language theory and implementation, particularly for functional programming languages.

The problem with reading a lot before coding is that you learn the knowledge ("what to do") without learning the wisdom ("when to do it). Even if you specialize in one area, there's a large body of practical knowledge that people do unconsciously when they're working on a problem, but don't think to write down in a book. Or if they do write it down in a book, you won't understand the context for it until you've been in several situaions where their advice has both worked and not worked. When I was studying this stuff in college, I read multiple books on each topic, it "clicked", I knew when to use each technique - but I didn't know when not to. As a result, my designs tended to be jam-packed with features. It takes experience to realize "Oh, metaclasses are really handy in this one situation...but most of the time, you are better off banning them because the cost in understanding your code is greater than the code simplification they give you."

It does get better - write a lot of code with the new language features and you'll get a sense when they're not useful, or how you can apply them to more mundane languages. You can define a decorator in Python to do Maybe monads, for example:

  def maybe(decorated):
    def worker(*args):
      if any(arg is None for arg in args):
        return None
      return decorated(*args)
    # Standard decorator machinery
    return worker

(This doesn't mean you should; this usage is pretty non-idiomatic and will do strange things in edge-cases. That's my point though...the only way to figure out when it's worth it is to try it out in a few situations and determine when it makes the code simpler.)

Experience.

A lot of being a good programmer doesn't have to do with technical skills.

Take a compilers course. This was required at my school and I figured it would be boring (I mostly likely the theory classes). I was wrong! Writing a compiler really made me understand what they do. I had seen a lot of people who were trying to appease the compiler. Instead, the compiler is now my slave.