mental switches

3 minute read

In the beginning of my career, I found myself very concerned with coding “best practices”. Everything from “did we follow a good design pattern here” to is “everything tested in the correct way”. I tend to say that I “love all things beautiful” and that includes code. I get a kick out of code reading nice and looking pretty, whatever that means – it’s just a matter of my own taste (and I’m not even sure my own taste is that good). As good as that attitude was in the start of my career (it pushed me to learn as much as I could about writing good code), it made it painful when contributing to code I didn’t like it, even if it was perfectly sane code.

Over time, I came to realise that it’s a waste of time thinking like that. In 99% of cases, the thing you’re actually concerned about is providing value for your users, not the arbitrary, ill-defined beauty of code. That being said, I still am a man of my taste. Like with all things life, just because you believe something, doesn’t mean it’s easy to put into practice. Hence, I came up with a way of dealing with it, which for lack of a better name, I’m calling mental switches.

It’s actually nothing special at all. All a mental switch is telling myself to approach my work with a mindset aligned with the actual goals I’m trying to achieve. For example, if I’m trying to ship something of value to users, my mental switch is: “just focus on shipping the feature, don’t worry about the look and feel of the code base as a whole”. This helps disarm my own personal taste and worry about the actual thing I’m building, not lamenting about all the ways the code could be easier to read or starting to refactor bits that just don’t actually need to be refactored.

When working on my own code bases for fun, I often rewrite them 1000 times. This is my “express yourself as much as you want” switch. I can waste copious amounts of time just trying to make my code read better. Its code written for the sake of joy and I’m the only one who’s ever going to touch the code base. I can write it exactly how I like it.

This changes if I’m writing code for any personal product ideas I have. I’ve previously been disarmed trying to choose an “ideal stack” (use all the new shiny things!) and writing code as tastefully as I can.

I find myself pondering over the typical dumb questions like “will it scale” or “is this the best technology for this” and the technology in question is Postgres. I can only thank whoever is up there that I don’t know anything about k8s otherwise I’d have to add “should I use k8s” to my list of unnecessary technical questions. As you can see, this line of thinking is silly. My mental switch for this scenario is “choose proven technology and move on with it”. The most valuable thing you can do when going from 0-1 is to actually go from 0-1. That’s hard to do when you’re posturing and pondering about technology choices that you likely won’t even have to deal with as a founder should the business become successful. That’s not to say you shouldn’t give it some thought and avoid burdening your engineers down the line, just that, they’ll figure it out, just as they always have.

The summary of this all is that, by having a mental switch that changes how I approach work, given the context, it makes it easier to not waffle around unnecessarily unless I actually have the time and space to. It’s a decent work productivity hack and one I’ve increasingly used to get things done.