I already have problems

During my undergraduate degree, every upper-level class terminated in a large project. Whether doing these projects alone or with a team, one common assumption was that you would have produced something resume-worthy at the end of the project. However, this assumption with a couple of problems:

1. Almost always the scope of these projects was constrained relatively narrowly to the course material. After all, this was a project for the course, first and foremost.

2. The definition of a completed project was always very academic, in the sense that you needed to have some sort of demonstrable “result” to be viewed by an audience.

Overall, I felt bad about each of these projects in some way or another, mostly because they provided a very wishy-washy line item to my resume, while doing little else. Oftentimes---especially when working with a group---there was a tendency to pick an “interesting” problem. After all, who wants to run a cool algorithm on boring data? However, a project appealing to a wider audience often lead to a final product that was entirely static: An algorithm that solved a problem based on some predefined dataset, or a paper detailing the research process of gathering data and applying an algorithm. (My degree was not in Computer Science, so I can’t speak to whether all [or even most] people in tech feel the same way about these contrived undergraduate projects.)

The reason I bring up my lackluster undergraduate project experience is to draw a comparison to the mythical “side project” so often talked about in circles of entry-level tech candidates. Oftentimes, people will approach side projects like they approach a project assigned to them by a professor: Try to find something flashy enough to have widespread appeal, and then work on that self-imposed problem with an eye toward some presentable product. I have found that, for myself, this approach to “side projects” is a fool’s errand.

I already have problems.

I have problems that are mundane and repetitive and put me to sleep. I have problems that wouldn’t appeal to a wider audience based on only a summary in a README, or a one-line description on my resume. The kicker is that your job likely doesn’t have these problems either. Real-life problems don’t have an audience; they have customers, and customers aren’t interested in a problem based on a resume line-item.

However, most degree programs (and some online forums) rip you out of your real life to plunge you into a world where the Spotify API is the most interesting thing in the world, and the travelling salesman problem is relevant. I am convinced that this approach is a disservice, or at least was for me. The only “side projects” I have ever gotten real traction on were ones that paid off for me in a practical way, where the solution gave me tangible benefits.

The “contrived problem” approach seems to be especially prevalent in data science, where problems even approximating real-life problems often occur only at the scale at which corporations operate. Not many of your everyday issues involve large-scale datasets. I’ve heard of some people having success with tasks like facial recognition, using machine learning for a(n at least approximately) practical purpose. However, most “side projects” I saw among my peers involving machine learning seem to devolve into either an academic exercise or a kind of “proof-of-concept” of an algorithm on new data. That’s not to say that these projects were useless. My peers likely gained some good working knowledge of machine learning algorithms. In the end, doing anything technical is better than doing nothing. I’m not pitting the classic contrived “side project” against sitting on the couch.

For me, the type of payoff that comes from solving a problem for a problem’s sake isn’t the same as solving a problem to get it done. Solving a problem because you need the solution gives you a solution at the end of the day. Also, aiming for a practical solution gives you a better approximation of a real engineering experience. No real-life engineering project is focused only on presentability to a future employer. Also, no real-life engineering project is ever “done”, because problems don’t disappear. If you have a side project that solves a problem that you actually have, the benefit to you isn’t that the project adds to your resume, it’s that your project lets you flex the same muscles you will use in real life. Doing a flashy project for your resume feels to me like becoming a bodybuilder so that you can get a physically-demanding job. Are you better off than the average person? Absolutely. But if you really want to just work, then start doing work.

I’ve only had one interviewer ask about my “presentable” side projects formerly featured prominently on my resume. I use my current side projects daily, and even though nobody knows or cares about them, I get to experiment with technology that matters to my everyday life. This contrast has informed how I see side projects. Even just a couple of years into my career, I don’t think it is worthwhile to do extra work for the sole purpose of showing off that I did work. I like solving my own problems, with the side benefit that I get practice solving problems.