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.

 

One thought on “Planning your attack & other programming lessons I’ve learnt

  1. (2) well i noticed there’s a diraagm at the end of that sheet manual is in fact a pic of the old version. also i found interesting info, for example [is.gd / 3NX7UY] [is.gd / kElpgz] (short urls to madcatz site) there exist: universal model 6320(*) ps-only model 8020 microcon (means no shift stick) ps-only model 8230(**) in colours black/yellow, black/red, grey/blue, grey/red please do post your model numbers if they’re different (*) exists pdf manual. (**) exist pdf manual sales? sheet

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>