I recently worked in a team for a class project and I think the most educational thing I took from that course was how my teammate worked. I’ve known a lot of people who are good at CS, but it’s the people who I considered to be great that slightly eluded me. What was the thing that made them slightly more effective, slightly more in command of their material, and slightly more comfortable in the field. Until said class project, I think I missed one huge aspect of it - the tools that they used, or more often, built for themselves to aid their productivity.
For instance, we were tasked with building a mildly complex VR controller interaction system in Unity. The catch was that we could only use the controller while in the lab. And if you aren’t familiar with Unity, know that it is quite slow and annoying to iterate with. As such, building a working controller interaction meant sitting in the CS basement for hours with no snacks nearby (the horror). What my teammate did that surprised me, was that he built a bare bones emulator for that controller in Unity, to simulate how it might behave. Motions of the controller were aliased to keys on the keyboard and a simple cube visually represented the controller in the game scene. The result? A sufficient emulation of the controller that let us work at home, avoid the controller API, and test the essential parts of the system. It probably took a short while to build this, but it saved us many hours.
I’ve increasingly realized that good tools can be an essential part of the development process. What may seem like a time sink in a tangential direction is simply an investment in a more comfortable journey ahead. And these tools can be temporary, serving just for the use case at hand but they can still make an impact. What’s key here is to be cognizant about our personal frictions - the hidden forces that make tasks more difficult or unappealing to us. Anything that we can do to remove the slightest friction is time well spent - friction is hard to notice but the second you are without it, you’ll realise the difference.
Once a teammate of mine set up email alerts to monitor our experiments that ran on a server, a seemingly small thing but one that stopped us from babysitting our experiments, letting us move on in life. Now, I find myself wishing that I had a similar system for my experiments at UCSD since I often stare at my kubernetes pods just to ensure that they don’t die randomly.
I should probably build that.
PS: This blog is in some ways my personal evidence for building better tools for my workflows. I recently integrated notion with my jekyll theme and set up Github actions for automatic deployment of the website. By decoupling writing from the web-dev process, there’s virtually no friction in blogging anymore.