What are the best-kept secrets of great programmers?

Answer by John Ohno:

  • A bug is not a property of the code; a bug is a property of the programmer. If you have a bug, that means that the model of the problem in your head differs from either the actual state of the code or the actual state of the problem. Fix your mental model of both and then 'fixing' the bug becomes simple.
  • Every language and programming paradigm is a tool. Every 'best practice' is a tool. Yes, even your favorite. Use tools when they are useful, and don't use them when they get in the way. Once you start a project, you are all but locked into the tools you chose — so, choose the tools that, at the end of the project when the code is two maintenance cycles away from being thrown away and rewritten, you would have wanted to use in the first place. This means using object orientation only when the best way to represent what you're trying to do is objects, and using functional programming only when your code benefits from a functional style. Ideology only gets in the way.
  • Temporary programs aren't. Particularly if you are in industry, assume that you will still be maintaining any piece of code that goes into revision control or becomes part of a process for the next ten years, unless you rewrite it first. Write code that you will still understand in ten years, and use technologies that you used ten years ago and that you expect you will still want to use in ten years.
  • Every language you learn adds to your toolbox. Every concept you learn adds to your toolbox. Some tools are less widely applicable than others, but having exactly the right tool is what separates very skilled programmers from your average CS graduate (who has, over the course of the curriculum, been taught some large subset of what academics in 1993 thought were the most widely applicable tools).
  • Don't neglect communication skills. The best design in the world is worthless if you can't explain it to your boss, and worse than worthless if you can't explain it to your replacement (when your boss inevitably fires you for putting a giant black box in the middle of a production system).
  • If your predictions don't match the operation of the system, it's your predictions that are wrong. Don't say "this is impossible": it happened. Human memory and human cognition is incredibly crappy. The behavior of the system is the reality you need to deal with. Don't let your ego prevent you from being a competent programmer and a competent debugger by privileging your mental model of the world over the world itself.

What are the best-kept secrets of great programmers?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s