What is it like working at an early-stage startup?
As a computer nerd, I genuinely love programming. I love to think analytically and solve complex problems and create a product from scratch.
Working full-time at iCIMS didn't really scratch enough of that itch for me. Sure, I was writing code and solving problems, but I always wanted to be doing more.
I would spend weekends working on silly projects, like creating a sports gambling bot, building a camera, or trying to algorithmically profit off of stocks. However, this didn't fulfill me quite the way I was looking for. I wanted to create more on my own terms.
One afternoon when I was scrolling through twitter when I came across the tweet below.
ShotQuality is looking for a part time web developer/software dev passionate about basketball and has experience working with account/user management, if you are interested DM me or reach out to simon@shotquality.com
— ShotQuality (@Shot_Quality) July 12, 2021
Thanks 🙏
At that moment, I felt like I finally found an opportunity for me.
I had heard about ShotQuality before and had seen them retweeted onto my timeline. Their goal is to contextualize shot attempts for each basketball team in unique and powerful ways. For example, how much more efficient is a Kevin Durant shot attempt compared to a Lebron James shot attempt? (~5 games into the 2021-2022 season, the answer is 0.18 points per possession)
I had looked into the site at the time, saw some little tidbits of stats that weren't behind a paywall, and thought it was cool. And I thought that was that.
After seeing the tweet, I sent in my resume through email and twitter DM. I didn't know what was going to happen, if anything, but I figured I'd give it a shot.
Shortly after sending, I had a 30 minute meeting scheduled with Simon, the founder and CEO of ShotQuality.
And after the talking through skills and requirements at that meeting, I was officially a developer consultant with ShotQuality.
Things happened really fast after that. I joined the company Slack, I was added to all the weekly check-in meetings, and was told to get familiar with the codebase before I started my projects.
And let me tell you - the codebase was a MESS.
The stack is a pretty simple REACT frontend and then a Python flask API backend. Flask handles all of the profile creation and user data, whereas all of the data is created through hourly python scrapers and then accessible through API endpoints.
The hourly Python scrapers are large singular files in dire need of refactoring. A large majority of the data analysis is done in a proprietary R file that is over 13 thousand lines long, and then are saved in 25 different csv files per game.
As a physical learner, I knew I learned best by diving right in. While I was a little overwhelmed by a new tech stack and massive files, I needed a project to start with to get my footing.
My first project was to automate account creation on payment through Stripe, a popular online payment processor. Basically, whenever a coach or fan completed & paid their invoice, there should be an account created with an email sent to reset their password.
Ultimately, the task wasn't too hard. Stripe has wonderful API documentation, making the process a breeze. I just created a webhook for invoice.paid events, and wrote some Python code to create accounts based on information in the event. The below picture is a very small snippet, without revealing any secrets of the trade.
After completing this project, I realized what makes a startup company a lot different than an enterprise SaaS company.
Usually, after completing a task, at enterprise companies there is a whole testing pyramid to complete to reach "definition of done," a term to represent total completeness. This includes unit testing, integration testing, and manual testing by another developer, and then regression testing before monthly releases. All in all, this process takes about an extra week in addition to the development work.
At ShotQuality, there was ZERO testing. There was a strong emphasis on speed of development work, and not nearly as strong of an emphasis on reliability. In fact, there did not exist any testing frameworks, issue tracking systems, branching strategies, commit syntax, etc.
We had zero programming paradigms or best practices. I knew that there was a lot of opportunity there.
Here is a list of some of the systems I implemented:
- To start, I felt like I needed to implement some unit testing framework. Looking into the options, seemed like pytest had the biggest userbase and the most documentation. I added unit tests for the Stripe automation ticket, and advised the same to be done for all future backend changes (although that doesn't always happen).
- I followed in the footsteps of iCIMS best practices and instituted Conventional Commit message specification to have uniform commits.
- As we speak, I have been pushing trunk-based development for monthly release branches & regression cycles. Nothing has changed yet in that regard, but hopefully down the line.
- We have been moving towards ticket-based task management, albeit inconsistently. I advocated for Notion, but we are currently using Trello.
- I have documented all of the above & other more ShotQuality specific solutions in the GitHub's README.
Even with all the new positive changes to our coding practices, there are still a multitude of problems that bubble up. Every customer is massively important to the end line, so it is common to work nights/weekends to dive into a customer-specific bug. And with the lack of great infrastructure, bugs happened constantly.
After a few months of backend changes to the Flask API, Python game scrapers to pull data from KenPom and ESPN, and staying up past midnight to update site data, I had to momentarily step away ShotQuality. It took up too much of my time for a part-time gig, and I felt like it was more of a chore than a fun project.
But, I hope to get back to ShotQuality soon. They have a killer product with a slew of great advancements coming. The CEO is incredibly passionate and hard-working, who understands a lot of the infrastructure related concerns from the developers.