“Get the code working first, then worry about how to clean and optimize it.”

For me when I learnt about optimization and how one thing was better than something else, I tended to focus on that. I’d have a picture of that in my mind, and would try to write as clean of code with less hacks in the middle and as optimized as I could in the first go, which slowed me the way fuck down.

After he said that to me, I realized I was stupid and just wasting time if I worried about that from the start. Would waste time, and just cause more headaches from the start than it was worth.


Oh also another one, I knew never to trust the client from the start but the way he said it was funny. “Never ever trust the fucking client, don’t trust them with anything. I trust Satan more than I trust the client.” πŸ˜‚

  • 13
    First make it work, then make it right, then make it fast, then make it small.
  • 0
    I only realized that yesterday.
  • 1
    Or: Avoid premature optimization
  • 0
    I don't always agree. For me it's often:

    1. Make it work
    2. No time here is a new project..
  • 3
    Depends. I just try to make it modular af (many independent functions) that then are easy to optimize.
  • 1
    This is a fine line.

    If you can do something right to start then do, even if it’s the second or third iteration.

    I usually do a rough, disgusting version and then refine over a day or two.

    Premature optimisation is an issue when you spend all your time on it and not building shit.

    But similarly, getting it done and then delivering it tends to lead to project managers getting you to move on, and then you’ve got a lovely case of technical debt on your hands.
  • 1
    I think that with experience, you tend to cultivate habits that let you write better code on the first pass, which reduces the amount of refactoring. But if you ever get so good that you write perfect code first time around and don't need to review and refactor then you'll be kidding yourself.
Add Comment