Sometimes I joke that the best program I ever wrote was a VBScript Macro in Microsoft Excel just before I made a career change. It certainly wasn’t the most elegant code I’ve ever written but it really got the job done. The macro helped cut hours of administrative formatting work that I got tired of doing in my day to day. When I shared the tool at work it spread across the organization quickly without me having to lift a finger. Even after I left I heard the macro made it as far as departments in Spain. I wrote it over a weekend in my room, thanks to the discovery that I could Google almost anything and find an answer to get me unstuck. It was the catalyst of what has become my career in software.

Sometimes I find myself dreaming of developing a tool in just a few days and having it spread with such fanfare. What I’m not so sure of is whether no opportunities like this still exist or I’m almost blinded by experience. My mind jumps too deeply into the technicals and makes work for itself that is divergent from reaching the end goal any way possible.

I may be understating the total time it took to develop my first useful tool. After all, it took over a year at my job to understand the problem space and feel enough pain to want to attack it. However, I’m not interested in discussing problem discovery as much as solution implementation. Once I had the idea to fix something with code I got the job done fast. Some days I fear that the experienced developer in me, if faced with the same problem, would start thinking too abstract. In 1 to 2 weeks time I would deliver something of equal usefulness but with a cleaner codebase that no one may ever actually see or need to improve on.

Maserati Problems

I’m not sure where I first heard the term “Maserati Problem”, but it seems to have stemmed from the startup movement in tech. In layman’s terms, it is a problem you create based on the assumption of future success. i.e. What if customers experience XYZ after we have 10k daily active users?. If the solution to that hypothetical adds weeks to the project, then now may not be the time to solve the problem. Developers can be prone to creating Maserati problems both in personal projects and workplaces. We might be even worse at this when it comes to personal projects because there’s no one to slap us across the face and assert what is most important.

Quality Engineering vs Stubbornness

There is no silver bullet solution to this problem. It is simply a matter of continuing self awareness. We must remember to not be too proud of our code. We are here to solve problems first. Sometimes there is a necessary trade off between delivering on time and getting it perfect in the first try. It is up to you to understand the structure of your organization and cater appropriately to the business needs. This varies greatly depending on company size, company stage, team size, your job description and more.

In personal projects it’s okay to do something for the love of code alone but if that wasn’t the initial goal, then where are you now? I try my best to state one of two possible goals in personal projects - Learn something or ship something, but don’t expect both. My personal track record of sticking to this doesn’t always work out, but I try.

Closing Thoughts

I find myself admiring both expert coders and scrappy coders that ship products. Some apps that impress me get developed by self described designers who did whatever it took to make their interface vision work. Whether those works have long term viability varies. However, assuming that the initial product is well received enough there will be time, motivation and maybe even money to make it better.