When I concluded my last post, life in side hustle land was good. I had created a spreadsheet to assist my wife in calculating child support guidelines. This allowed her to cancel her subscription to her existing app. On top of that, I also really enjoyed working on this project. My wife’s work is far more exciting (not to mention depressing) than my job, so over dinner, she regales me with stories about her courtroom victories or unruly clients. But I don’t often hear about her routine day-to-day work. This had been an opportunity to see that and to collaborate on something other than raising kids or planning vacations. And at the end of it, my wife truly felt that the simple spreadsheet we had created was better than the existing products on the market. The next step was to test that theory with potential customers and see if they agreed.

Let’s take a quick step back first. When I created a spreadsheet to enable my wife to calculate child support amounts, I wasn’t just indulging in my love of spreadsheets. A spreadsheet was the quickest way to get my wife off her existing app before her subscription was up. It also allowed me to focus on the problem to be solved instead of worrying about the technology. But if we were to turn this into an actual product, a spreadsheet wouldn’t cut it. We needed to create a minimum viable product or MVP. For those unfamiliar with the concept of MVP, it’s the version of a new product that allows you to gather the maximum amount of proven customer knowledge with the least effort. In other words, what’s the quickest way to get something into customers’ hands that solves their problems and allows you to get feedback?

My initial thought for our MVP was to create a simple application that mimicked the spreadsheet. I’ve glossed over this point, but it’s probably worth addressing: how can a spreadsheet be better than an application dedicated to solving a specific problem? Easy. The application was flaky, overly complex, and looked like it was from the 2000s. By extracting the core logic for calculating child support and sticking it into formulas in a spreadsheet, we solved all those problems. It was simple, it wasn’t buggy, and despite being a spreadsheet, it looked more modern. It was essential that we carried over those aspects into our new app. We’d also need to allow for saving and loading the data. To do that and limit who can access it requires users and authentication, so we’d need to add that as well. And that’s it. We already had a long list of other features we wanted to add, but it was necessary to nail this core set quickly to get the app into users’ hands and get valuable feedback.

Now that we had our requirements, it was time to start development. The quickest way to get started would have been to leverage what I knew. I had just finished teaching a college-level course on web application development. But as anyone who has attended college can attest, it’s excellent at teaching theory and basics, less great at imparting actual practical knowledge. So, instead of introducing the latest time-saving, tedium-reducing libraries that most sane engineers use today, I taught the tried and true basics that have been around forever. Which meant that’s all I knew also. Regardless, I could have thrown a perfectly acceptable MVP that would’ve been cutting-edge ten years ago and been up and running relatively quickly. But I had something different in mind. And this is where things got sidetracked.

I’ve loved learning all my life, but as I’ve grown older, I’ve become very practical, sometimes to a fault. The siren call of knowledge is no less intense, but the demands of being a responsible adult are often stronger. When I was younger, I would study random topics like theoretical physics, bonsai, and whittling. However, I haven’t picked up a physics book since college, my bonsai have long since died, and my whittling knife is in a box somewhere. While those are all interesting topics, what’s the point? With two young kids, my wife running her own business, endless things to fix around the house, and a million other responsibilities that come with being a middle-aged adult, time is my most precious resource. There must be a compelling reason if I’m investing time into something.

I gave up coding full-time almost a decade ago when I moved to managing people. So while I am well-versed in the latest research in organizations, people management, strategy, and all the other things that come with leading teams, my development skills are rusty. I never realized how quickly tech moved until I looked up one day and realized all the languages and tools I was proficient with were considered relics. I don’t want to be that guy stuck in the past, but I’m not going to just pick the newest language and start writing code. Given my practical nature, there must be a better reason beyond learning the latest fad.

Enter the child support application. Here was the excuse I’d been looking for to learn new tech. What could be more practical than a potentially profitable application? And given the rare opportunity like this, I would take full advantage of it. I already knew JavaScript, so why not learn React, the most popular JavaScript framework? And since we wanted to host it in the cloud, what a great chance to dive deep into AWS. And not just EC2 instances; why not find a way to use as many AWS services as possible? Looking back, I can see many smaller learning challenges I could’ve taken on. Write a basic JS app and host it in AWS using EC2. Or use React and find a way to host it locally—endless permutations of quicker, easier challenges. Instead, because of my pent-up desire to learn, I decided to tackle it all. At the same time. With predictable consequences.

Attempting to learn almost every aspect of a tech stack at once while writing an app from scratch would’ve been challenging at any time in my life. But I had vastly underestimated how long it would take me to learn so many new technologies. I had not taken into account kids. It turns out that trying to learn something new while being interrupted every other minute is an exercise in futility. I didn’t realize this then, though, and assumed it was just difficult to teach an old dog new tricks. And then a 3-day weekend came along. I had been trying to learn React for almost a month, but nothing was sinking in. I was reading the same tutorials repeatedly and going nowhere. Then, during this 3-day weekend, I had almost two days without kids. I made more progress that weekend than I had the entire previous month. I realized then that uninterrupted time was the key. So now, if I need to come up to speed on a complex topic, I either wake up in the wee hours before everyone else or wait for a long weekend.

When I started this project, I thought my priority was getting an MVP into potential customers’ hands as quickly as possible. I had thought that just by narrowing the features down to the bare minimum, I had ensured a quick path to delivery. However, MVPs aren’t always just about the feature set. They are also about the tech you use to develop those features. I had doomed any chance at timely delivery by prioritizing learning new technologies over-delivering functionality and underestimating my learning ability. However, I’ve gained a tremendous amount of hard-earned knowledge over the past months, which should accelerate future progress. My wife asked the other day how difficult it would be to add additional features post-MVP. I just laughed. After everything I’ve been through so far, everything looks trivial in comparison. So, while my desire for edification may have delayed progress, it has not stopped it. The side hustle continues.