I just spent most of the day refactoring my own code.
Maybe it’s just me, but I’m incredibly picky about how code is structured and written. I can’t stand looking at my own work for too long without finding something that could be done better—made more elegant, polished just a little more.
But balance is key.
Oddly enough, I’m really messy when I prototype. Too much structure at the start just slows me down. I throw in dummy data, declare components inline, repeat blocks of code, and write quick, one-off functions right where I need them. It’s all about speed—getting the feature working as fast as possible while uncovering potential edge cases and hidden complexities. It’s a raw, chaotic process, but it helps me truly understand what I’m building before worrying about how it looks under the hood.
Once the core functionality is in place, that’s when the cleanup begins.
Refactoring in Layers
1. Connecting Real Data
I start by replacing static dummy components with dynamic ones. It’s still messy, but now I’m working with actual data, testing different inputs, and exploring edge cases.
2. Identifying Patterns & Reusability
I scan for repeated code. If a piece of logic appears too many times, I extract it into a reusable function or component. Then, I review all my helper functions—do they need to exist? Can they be optimized? Should they live elsewhere? Anything that clutters the component without adding value gets cleaned up.
3. Streamlining Data Flow
Refactoring often introduces breakage. Before moving on, I double-check that I haven’t accidentally severed dependencies or overlooked something that was originally necessary. Here, I also improve loading states and error handling (because let’s be honest, console.logs aren’t a real error strategy).
4. Polishing the UI
Now that the logic is solid, I turn to styling. I pull up Figma and refine the visuals, ensuring the component matches the design precisely. If something feels off, I take notes or capture screenshots to discuss with the designer or PM, making sure feedback is based on real implementation rather than assumptions.
5. Final Touches
Depending on the project, this might include writing documentation, ensuring Storybook examples are clean, or adding tests. This is the final step—separate from the actual building and refactoring, but equally important for long-term maintainability.
Why This Works for Me
I see prototyping as getting my hands dirty with clay before sculpting the final form. Start rough, refine over time, and gradually shape it into something precise.
Some might find this counterintuitive, but for me, removing the pressure of perfect structure upfront actually speeds up my process. By focusing on function first, I can iterate quickly, understand the problem space, and make better architecture decisions once I know what I actually need.
Maybe this approach isn’t for everyone. But if you ever feel paralyzed by the need to get everything perfect from the start, try embracing a little mess. Just start building. Have an idea of where you want to go, and let the structure take shape as you progress.