As a young programmer, I was eager to dive in and get my fingers dirty as quickly as possible—no need for a plan or a direction. I knew I could figure it out as I went.

Fast forward some years, add higher project complexity over a more extended period, and the lesson became clear: sometimes if you want to run for long, you need to run slower and have a plan!

Figuring it out as I went worked fine for one-day projects or one-week prototypes. But when bigger projects came my way, I got to a point where I could not remember anymore what my initial think was, where was I headed and why, and how to present my idea to new members on the team.

Although nobody likes to write documentation, I began to make a habit out of it, and I knew it would come a day when I will thank myself! By now that day has happened many times 🙂

What would I tell my younger self?

Writing docs and making plans is not sexy, and in general, your clients do not care for them. They need working software, not documentation. But if the project is longer than six months, a few problems will begin to crop up:

– you forget why you took the decisions you made with the initial design

– if you will need to refactor your code, and if it is not well documented (and if it lacks automated testing) the job of refactoring will take a long time, and you run a high risk of breaking functionality

– by using best practices, you future proof your code – you make sure that you at least don’t make the same mistakes that others made before you. You will make new ones, for sure, but your overall code will be much more stable, easier to maintain, and upgrade.

In conclusion, there is a time to be quick and messy (when you are prototyping), but then you need to slow down and think things through.