Tagged "learning"

Yesterday, I found two bugs whilst looking at a code coverage report. I tend to think that shooting for 100% code coverage adds unnecessary overheard - often the last few percent doesn’t give you much benefit, and takes a disproportionate amount of time to reach, but it’s useful to at least understand why particular lines of code aren’t hit by your tests. Perhaps those lines are dead code, or perhaps - as was the case for me yesterday - it’s because your code is broken.

One of the programming lessons I find myself re-learning again and again is this: It’s turtles all the way down 1. When I first started my current job, just after graduation, I was working in a frontend development rôle. The app I was working on involved storing customer data in a proprietary database system, and from time to time, I’d get stuck. Perhaps data wasn’t being saved in the way I expected, or perhaps operations on the database were slow in ways I didn’t expect.

See, I know nothing! — Manuel I distinctly remember being 17 years old, I’d just finished re-launching a site for a charity I was involved with1, and I confidently declared that I knew all there was to know about building websites. And I believed it. At the time, I was building sites in PHP, and like every other 17 year-old learning PHP, I’d built entirely my own system for managing the site.

Every once in a while, I want to start again. I currently have 6 different sites using Kaléo, a bit of software I wrote for managing Church websites, which I’ll write about another time. The code is stored in a private git repository, and synced out to 6 different places every time I need to make a change. Most these changes are fairly simple, and upgrading each site looks roughly like this: