How to be a better programmer

In response to a question about how to become a better programmer, Paul Penrod gave the following tips on a mailing list to which I subscribe. Many of these could apply to any profession.

I’m going to make few suggestions that might help you.

You don’t really need to apprentice under anyone, unless it’s your aim to adopt their style, thinking logic and methodology. The key to being a successful programmer is learning to think properly about the problem at hand, and be fluent enough with the language of choice to express yourself simply, but elegantly. Programming is an algorithmic exercise, that is part science and part art – mostly art. You need to develop a style that works for you and the problems you wish to solve, and that takes time and experience. It’s one of the few disciplines where [on the job training] is just as valuable – if not more so, than hitting the books, and listening to academics.

Over the years I spent a great deal of time studying what others did (along with their code) and figured out for myself what would work best in my situation at the time. There are some basic tenets that have come from all that effort:

  1. Understand the problem completely first.
  2. There is no perfect language for all problems, although C comes pretty close.
  3. YOUR perfect language(s) will be the one(s) that is(are) most compatible with YOUR thinking process.
  4. Keep It Simple Stupid – ALWAYS works.
  5. ALWAYS document completely what you did – you will thank yourself is six months time.
  6. Never turn down an opportunity to see what someone else did – they may have figured out a simpler, more effective way.
  7. Always be teachable.
  8. There is almost always a better way. Many solutions are at best, compromises.
  9. Learn what others did wrong and don’t repeat their mistakes.
  10. Don’t be offended easily.
  11. There are plenty of intelligent idiots, and few sages – learn to tell the difference and pay attention.
  12. Just because you can, doesn’t mean you should.
  13. Develop your own style. You are a unique individual, and you don’t think the same as anyone else.
  14. It’s an art form first, and technical second.
  15. Software is never “done”. It’s a work in progress.
  16. Have fun with it. If you aren’t enjoying the effort, it will show in the results.
  17. Share what you have learned with others. It pays dividends far beyond the code itself.

2 thoughts on “How to be a better programmer”

  1. Derek,

    While I can appreciate the logistical noodling you have done to deconstruct what I wrote. You missed the point by a very wide margin.

    Each of these maxims are true on their face, but just like Poor Richard’s Almanac, if you tried to live by every word in every situation, you’d fail miserably. They are meant to be applied as needed.

    And yes, it is an art form first, with a technical basis. One could make the argument successfully, that either music or oil paintings are simply a confluence of mathematical criteria that satisfy some golden mean – and they’d be right. But, only the master of that medium can create that golden mean at will (talent) – irrespective of the educated man who comprehends the mechanics.

    …Paul

  2. I would like to think that a better programmer writes better code, but I don’t see how much of this advice addresses that concern. Thinking of #14 in particular, I see how this might be applied to being a better programmer, but not how to produce better code. While it’s true that the more elegant solution is often the better one, the superiority of one algorithm over another is pretty objective in computing. A complexity analysis (big-O and the like) will usually answer the question of which solution is better. In the event that two solutions are similar in complexity, real world application would reveal which excels in performance and robustness. All those elements being equal, you can finally subjectively evaluate the solutions – making the artistic test the final one.

    What about the “art” of making code readable and maintainable? While these are valid concerns, a great programmer still wouldn’t sacrifice significant performance for their sake.

    As for developing an individual style, I think that’s fine for coding conventions and for those rare times when it really doesn’t matter what type of loop you use and similar circumstances, but there are advantages to conformity. Maybe my style dictates that I use a selection sort whenever a sort is called for. It’s a simple solution (#4 above), and maybe it’s fun (#16) taking a bathroom break while waiting for your algorithm to run, but #8 definitely applies: there is a better way. And in comparison sorts, it doesn’t get better than quicksort (because of the O(n log n) lower bound) so now #8 is out. I think it’s fine to adopt that style and not insist on rolling your own just because writing code commando-style fits your style.

    While at the outset the author downplays the need for a mentor, some of the advice relies on using others for advancement. I think the state of the art in coding has moved far beyond this informal approach. Enough work has been done in computing that we can, with confidence, say that one solution is better than another. My impression from this advice is that we should stumble through trial and error of solutions forever, always hoping to find something better. And then when we do, we won’t even know why it’s better.

    But I suppose this is the heart of the debate between academic and practitioner. Personally, I’d rather know why I need the ‘const’ keyword, and not just use it because I know the compiler complains if I don’t.

Comments are closed.