There is a common tendency when learning to program for people to move from language to language, or from tiny project to tiny project.
I think this is dangerous because oftentimes a particular concept in programming, say for instance orthogonality, doesn’t really sink in until after you’ve taken a project where you made a mistake around that concept far enough to see the problems surface naturally as a result of increased scale or complexity.
I mention orthogonality specifically, because I sat in a two separate programming interviews and explained what orthogonality meant in programming, and why it was important. I did a good enough job in the interviews that I was offered a job at that company (which I ultimately didn’t accept).
I then turned around a few weeks later in my day job and violated that principle by thinking that I could leverage an existing option being passed into a function to do something more than what it had been originally envisioned to do.
By the time the problem I’d created surfaced in my code a few weeks after that, I’d forgotten some of the context around what I’d done, and had a couple of days of tricky debugging before I realized my mistake.
Needless to say, I’m much less likely to make that mistake in the future, which illustrates one of the reasons that senior software engineers are paid so much more than junior software engineers.
There is real value in either having learned why not to do certain things, or having made the mistakes and learned from them. It it is hard to overstate how valuable it is not to make a mistake that sends an entire team of highly-paid engineers down a bad path that burns up weeks or months of effort.
It’s not just paying the salaries around that wasted effort that is costly. In some circumstances, a mistake like that can result in a competitor being first to market with a feature or product with a knock-on loss of opportunities that can value in the tens of millions of dollars.
All of which brings me to the point of this post. When working on a side project, I think that it’s important to pick something with enough complexity and scale that some of your design mistakes have a chance to surface. It’s better to learn the principles and never make the mistakes, but the more of those mistakes you surface and recognize, the more value you’ll ultimately be able to contribute to whatever organization you belong to.