What Works Today

I think about the Shiny Toy Syndrome every so often. A few years ago, I was being interviewed on a live stream, and the chat kept bringing up more technology I’ve heard of but haven’t used yet. It’s one of those nagging things in the back of your mind that you must catch up with the latest and greatest. However, having worked in software for the past decade, the latest and greatest is oftentimes obfuscated with what is known to work and what doesn’t. Best practices take time to discover. Many corner cases are not covered. And sometimes the new shiny thing is hidden from your readers or customers, so you are cranking widgets over creating value.

I love playing with new toys. But there comes a point where to get anything done with that toy, you have to learn from YouTube tutorials, blog posts, and Reddit threads. After mindlessly scrolling through this, your brain is too tired to start. (I’m looking at you Anki). Sometimes, it’s best to get started with what you already know today, and later pick up the tool if it meets your criteria.

If you know how to use Postgres and SQLite, use them! Are those new databases fun to play with? Yeah, I bet they are, but you know that will be time spent on learning that new tool. I’ve been in tutorial hell since starting my programming journey, and I realize it’s better to pick up a new tool when you’ve got a project in mind. But be warned, it should be the only new variable. If you try to stack new technologies together, you’re in for one hell of a ride. Like if you want to use a new Database, caching layer, and server framework, good luck to you. I don’t have the time or patience for that. I’d rather spend my evenings working on enough knowns.

That brings me to the Should vs. Must. In Elle Luna’s book, The Crossroads of Should and Must, she describes this pull of doing what you know in your gut is right. For her, it was painting on canvases in her private studio. I rarely think my pull is to learn R for the fun of it. It’s typically with a different goal in mind, like using R for statistical methods to run on a specific dataset to help me determine statistical significance. With a more specific goal in mind, I’m able to let go of my brain’s tendency to try and understand everything before getting started. An old co-worker of mine thinks about this like inertia. You need a certain amount of activation energy to get you started. When that goal is clearer in my mind, I’m able to lower that activation energy and get the ball rolling faster.

• Don’t know enough breadth? Call an expert to get you started.
• Don’t know how all of these technologies might go together? Oh boy, there’s an exciting new thing called Large Language Models that might be able to help make you a scaffold.

And many times, the technical aspects are the easiest. The harder part is the context in which you’re creating something. And understanding the market to validate your ideas. Or interviewing your customers to understand the needs of the customer.

Stick with the boring stack. In a recent episode of the Changelog, Kelvin Omereshone (K.O.O) talked about SAILS and being a boring stack. SAILS is a full-stack framework that’s been around for over a decade. It’s reliable. It’s using technology that’s been around for a while, hence “boring”. But that’s the point of being boring. It shouldn’t be there to stop you from what you’re doing. It should liberate you to think about the next thing.

Just start. In An Invocation for Beginnings, Ze Frank talks about all the little ways we start or don’t start. Starting looks different to different people. What you should steer away from is how an idealized version of starting should look like. Embrace the mess. Start with a brainstorm, a post-it note, or a lot of Post-it notes. Fill your desk and reject the idea everything has to be perfect-looking. Life is not a super well-organized bullet journal with neatly made gridlines. It’s imperfect and full of unknowns and assumptions. Start the process before making the template. Don’t edge towards a premature optimization. Just start.

Then, once it’s up and running, we talk about what will work tomorrow.