10 things I wish someone had told me before I started writing code…

  • There is no such thing as an absolutely correct or ‘perfect’ way to write an algorithm. Moreover, while there are plenty of wrong ways to solve a problem, you’ll almost never write a truly ‘wrong’ piece of code. In general, if the code works as you expect it to, it’s good code.
    • There is no such thing as a final implementation—even the Apollo mission code (which wasn’t code in the modern sense, but a system of wires and physical registers) required modification—in space no less.
  • Given unlimited time, there is nothing a computer can do that cannot be done with a pen and piece of paper. This includes machine learning, AI and anything else you can imagine; there is nothing ‘magical’ about a computer’s capabilities.
  • A new technology is only better if it’s better for you. Don’t chase the language/framework/library of the day, if it isn’t broke, don’t learn a new language to fix it.
    • It is often better to use an existing solution than to build your own from scratch. BUT, make sure you don’t break your back integrating another’s code if it becomes more difficult than writing your own. (This is especially important for recent CS graduates, but all programmers fall victim to ‘I’ll just make it myself’ syndrome on occasion.)
  • Computer programming is not the same as computer science. Knowing how to use a language or framework is just as important as knowing how to build a language or framework from scratch. Put simply, knowing how to create your own computer programming language does not automatically make you a more effective programmer—it makes you a better computer scientist. Conversely, being good at writing Java doesn’t make you a good computer scientist—it makes you a good computer programmer. Knowing the finer details about how a computer operates does not always mean one is good at writing code.
  • The user is always wrong. Not about what they want, but don’t ever expect a user to use a piece of software in the way you intended when you wrote it.
  • Don’t optimize a piece of code until you’ve fully integrated it into the program its intended for. In other words, make sure it works before you spend any time making sure it will work efficiently. Effectiveness should always take priority over efficiency, there are some exceptions to this rule (i.e. database design and systems programming) but the average developer will almost never run into them a situation where their code cannot be optimized after it’s been integrated.
  • Prototypes are not optional for anything that will take you longer than a few working days to implement in full. Even the world’s greatest minds cannot reason effectively about a system with more than a dozen working parts without a physical model of its final form sketched out somewhere. An artist does not start work on a sculpture until they’re sure about what they’re going to sculpt, writing a computer program is no different.
  • Strict adherence to concepts like modularity, composition, inheritance, state, paradigm/pattern compliance, etc., is always less important than readability: a line of code is written once and read many times, don’t ever ignore the reader, even if the only person who will ever read it is you.
  • Don’t write notes about obvious things. For example:

# instantiate a csv reader.
reader = csv.reader(file)

In general, if you write clean, concise code, the notes will take care of themselves.

  • Don’t write notes about how a piece of code works, write notes about what it does. If you need to explain how a piece of code works, it’s probably shitty code.
  • Not all programmers write code in their free time, and those who do are not automatically better at writing code than those who don’t. You don’t need to spend your free time doing your job to be good at doing your job: most accountants don’t go home and do accounting in their spare time. Don’t let the keeners make you feel like a shit programmer because you have a life outside writing code.