Planning your attack & other programming lessons I’ve learnt

I jump into code too quickly. I don’t think about the whole system, I just dive right in. I’ve made this mistake 5 times this year and every time I remind myself to slow down. I’m paraphrasing my old boss Bong Doh: “Don’t touch the keyboard until you know exactly what, where, and why. What the problem is, where you are adding code, and why this code will fix the problem.” When I don’t follow this rule, I pay with my time and frustration. As we all know, rushing leads to bugs, bugs lead to anger, and anger leads to the dark side.

Here are 4 more lessons I’ve had the pleasure of learning:

  1. Confirm all program touch points are functional before jumping into code.

    Example 1: Our signup emails weren’t sending and I thought our code was the problem. After spending an hour investigating the ‘problem code’, I learned that live.com marked our account as a spam account and blocked us from sending emails (Mailchimp & Mandrill are great alternatives to getting spam blocked).
    Example 2: Our videos weren’t streaming, and again, I dived into the code thinking it was a problem with the player. It turns out Microsoft Azure has problems streaming older .mp4 codecs, re-encoding the test video solved the problem!

  2. Understand what the code does before diving in.

    Example 1: I created a WordPress site and was editing CSS files to style the font and change some colours. I learned hours later, WordPress layouts have editors to easily change any kind of style and much more!


  3. Prioritize features and understand how important each feature is to the project. If a priority 1 feature is taking 20% of your overall time-budget, it may not be worth it.

  4. Sometimes a good enough solution is good enough! Don’t let perfect get in the way of good. On the other side of the coin, a quick-fix stays much longer than you’d like.

    Example 1: During a Startup Weekend blitz, I was in charge of building our prototype. I invested too much time perfecting the prototype. The prototype was only 1/4 of the business, and I should have spent more time developing our pitch and slide deck.