Ponderblogs,a collection of creative blogs from the Ponder community.

Perhaps this is better explained through example: Next.js is an amazing framework. After writing the Ponder client in standalone React, writing the blogs site with Next.js was a revelation. It allowed me to build fast and focus on the important aspects of the product. As we were beginning to build, Next released a new feature called Incremental Static Regeneration (ISR), which did on-the-fly static site generation at request time instead of compile time. It was way faster than SSR, worked like magic and had minimal setup. Unfortunately our feature-set included the ability for authors to change the theme of their site, and there was no way of making that feature "feel" right with ISR, since one couldn't invalidate the existing cache across all the blog's pages at once. It was a painful but right decision to use SSR instead no matter how much better ISR was in every other respect (someday I'm sure they will introduce partial cache invalidation).

In a way I think both me and Dave (co-founder) really like polished experiences (in design and code respectively). This being our company and it being a startup we learned that good and working is better than perfect and under development. This also led me to develop better practices for incremental refactoring.

The drive to rewrite something is especially strong when you are new at something. You're learning so much so fast that pretty soon you realize you could've done things so much better. This feeling felt like a trap. What is paramount is results in the form of having a working product. However, I got much better at achieving the same result by instead doing incremental refactoring which helped me keep the speed of development while also increasing stability.

Even in a development team of one I sometimes faced the issue of wanting to change the way I did something, either stylistically or syntactically, because I learned new things or people showed me better ways of expressing things. When you're iterating fast though, I found 99% of the time it's better to stick to a correct (if not perfect) set of rules, have a linter enforce them and just forget about it.

Last but probably the most valuable lesson for me was that it is not enough to maintain my mindfulness practice as my work volume fluctuates. It is imperative that my practice grows proportional to it. There's a certain momentum (what I've heard being referred to as "codebrain") that my mind builds when programming that if left unchecked will continue on and bleed into the rest of my day (or most often, night), resulting in a too active mind, less clarity and less sleep, in turn affecting the work. Ironically, I've found it's especially necessary for me to do this when the work is the most fun. I learned to stop frequently and take some time to meditate, then go back to work or go back about my day.