What problem are you trying to solve?

A quick story about my first “real world” lesson with coding.

In my first job out of school, I was super lucky to work with some really talented folks. This was my first time working in “industry”. Up until this point, every project was limited to the length of a semester and most problems were abstract and theoretical.

In one of my first projects, we had user generated content that could be edited by anyone and I was tasked with designing a system that could keep a record of changes. I thought through all the problems that could be encountered and all the edge-cases I could fathom. I leaned on my understanding of source control and code diffs to figure out how changes and conflicts could be managed flawlessly. I presented my plan to my manager—Tom Pinckney—and detailed a very thorough, complicated plan that would deal with this problem in a way that I thought was “perfect”.

He thought about it for a moment and then asked in a matter-of-fact way, “what problem are you trying to solve?” We talked through the problem at hand covering details such as the size of the data, the complexity to build this solution, the potential lifetime of this feature being quite short as we test and iterate on various ideas building this company, and ultimately identified a much simpler solution.

Ever since that conversation with Tom, when I’m designing a solution to a problem and my impulses want me to dive headfirst into thoughts of grandeur about the beauty of abstraction and the limitless opportunities of code, I take an extra moment to think about the core purpose of what I’m building, how much work it will take to build, how long it will need to be supported, the implications of how it will be used, the type of data that it will handle, and other practical concerns. I ask myself, “what problem am I trying to solve?”