I’m working on an app that uses a bunch of flows I haven’t touched in a long time (it’s primarily server-based, and I’ve been defaulting to serverless/client-first architecture for a while now) and it’s a good reminder of how super messy code can end up in production I’m writing it as I’m learning the new tool + re-learning some Node/Express techniques, and the results are all over the place but I want to ship clean code, so I’ll actually end up building this app twice. once I get it built, I’ll make sure the functionality is all complete, then I’ll do a heavy refactor to clean up the code and make sure the messy parts that happened as I was learning don’t become the Final™ shipped code there are a few benefits:

  1. it helps me reinforce what I just learned by immediately revisiting the flows
  2. the cleaner code is written with the full context and understanding I have now vs. the learn-as-I-go context that I started out with
  3. I get the benefit of looking at the code with fresh eyes, but not so fresh that I’ve forgotten how and why I did it the way I did it — helps me clean up for maintainability vs. this becoming a rats’ nest no one knows how to work with

time-wise, if the initial build takes me a couple weeks, the rewrite usually takes a couple days (< 25% of the first build time, usually) it’s a luxury to be able to take the time to refactor like this, but whenever I can it’s my preferred way to go. I’ve never regretted the “build it twice” approach