I have always been drawn to computers. At five I could power one up. By eight I had memorised the MS-DOS commands. By eleven I was writing programs with some confidence, and I enrolled in a programming course to get better. The instructor was a top student at the local college and quickly became someone I wanted to impress. Then came a test I still think about: build a simple system for a supermarket. We were given basic input functions and asked to produce straightforward outputs. It seemed easy. I felt confident I could handle the logic quickly. So I decided to go above and beyond. Instead of focusing on whether the thing worked, I poured my energy into an impressive, stylised interface. As the clock ran down I realised what I had done. With minutes left, I had a beautiful shell of a system that did not solve the problem it was given. An F for a non-functional system impresses nobody, however good it looks. A B for a working solution, however plain, keeps you in the game and gives you another shot at an A. I catch myself buying paint before cement more often than I would like to admit — the dashboard styled before the pipeline is reliable, the API documented before it is correct. The instinct is not laziness. It is that the visible work feels like progress while the foundational work feels like delay. Build the foundation first. The paint is still there afterwards.