Think first, code later

As a 39 year old programmer the most important thing I've learned is that my subconscious brain is way smarter than my conscious brain and the best way for me to solve a difficult problem is to think about it for a little bit and then not think about it for a while.

Later when I'm walking or in the shower or just waking up from sleep, a solution far better than any I came up with using focused thought will suddenly appear nearly fully formed in my head.

Which is another reason why the "normal" 50+ hour working week is so harmful to startups.

If all you're doing is coding and sleeping you're not leaving any time for thinking.

This is a simple consequence of the fact that you usually don't know everything and can't create an idealised long-term plan up-front. Instead, you start with certain goals and try to implement a sensible system that meets those goals. As time goes by, your goals change or you add new ones, and you have to adapt that existing system to match.

Often, during the time since the initial development was planned out, you may have developed newer techniques for solving your problems, or you may have new tools available that weren't before, or you may have worked with some new people who have better ideas about something. In short, you may have a better way to do things than before. Now you have exactly three choices:

1. Stick to your existing design/ideas and don't use the better ways. (Pros: Maintains consistency and doesn't incur (re)training overheads. Cons: May cost more and/or get worse results for the new work, or may simply not be possible if you need a new approach to satisfy your new goals.)

2. Use the better ways, but only for new/future work. (Pro: Best cost and results for that new work taken in isolation. Cons: Might mean an entire new design co-existing with your previous one(s), with potential compatibility problems, integration costs, future maintenance overheads, etc, and might cost more to implement separately than it would have done if you'd known ahead of time and created a more general design to support both the old and new parts earlier.)

3. Switch everything to the better ways, a.k.a. The Big Rewrite. (Pros: Keeps your entire system using the best possible tools/ideas, and keeps the whole code base consistent and systematically designed across the board. Cons: Can be extremely expensive relative to incremental changes, you can easily lose little fixes/improvements that had been carefully worked into the original code base over time, and you may have to retrain some of your team before they can work with the new version.)

This is an exhaustive set of your options if you're going to do that new development but your team and the world have moved on since the original work. Every one of them has at least one serious downside, and unless you do a full rewrite across your entire code base every time you develop any improvement, those downsides always include some degree of inconsistency or stagnation.