# Progressive Coding We're often faced with - what feel like - insurmountable problems; complexity can be daunting, leaving us paralysed by the irrational need to have a perfect solution before even writing any code. Over the years, I've gravitated to creating patches in a style that I term "progressive coding" where I iterate on small - atomic - pieces of functionality, with the understanding that solutions rarely emerge fully formed. I don't believe it's about being lazy, or settling for something that "works"[^1] it's about recognising that programming - like life - is iterative. By breaking down large problems into small, manageable, chunks we progress forward at a consistent rate. [^1]: Be careful with "make it work, make it right, make it ~~performant~~ delightful" as you'll find that people often sack off the latter two. Here's how I apply this principle: * **Close Open Loops:** For every unanswered question or unresolved issue you encounter, write a TODO. This serves to close open loops; you can focus on the important in the knowledge that you've left a descriptive reminder to yourself. The goal, is zero TODOs before check-in (whether that's by resolution, or the creation of a ticket). * **Embrace Change:** Focus on the bigger picture, don't get bogged down by trivial issues like error messages and documentation; leave a TODO. Code is always evolving, be resilient to that; do the trivial, in-bulk, at the end. * **Self-Review:** We hold ourselves to a higher standard than our peers so why put code up for review that you, yourself, haven't reviewed. Prepare your code to [[Software Engineering/Crossing the Line (Code Review)|cross the line]] by looking at it from another perspective, break it into chunks if you can, and comment where there's ambiguity. * **Iterate:** Solve one problem at a time and iterate towards a complete patch. You'll often find that solutions settle into place; by solving the easier problems (TODOs) the harder ones (TODOs) become easier because they weren't foundational (e.g. they build from your other changes). This philosophy can, and should, be applied at multiple levels; given changes should be finite and atomic, you can iterate progressively by building bricks (patches) then assembling a house (features); where the foundation is [[Software Engineering/The Process of Designing|design]]. Progressive coding isn't about speed[^2]; it's about clarity, grace and control. It allows you to make incremental progress, build confidence with each step, and ultimately deliver a more robust and maintainable solution. [^2]: Although, with more haste, there's less speed.