Just use {{my favorite tech}}...

Dec. 30, 2024

Here’s some shit developers say to each other when the other person is stuck and we don’t actually have an answer to their problem.

These variously change over the years, but the message is the same: you wouldn’t have this problem if you used my preferred tooling. By the time I ask someone else for their input, I might be desparate enough to drop my tooling, but I’ve substitued one problem for the burden of switching to a new tool.

How often does this help me toward my immediate goal? Not never, but rarely.

We Do This To Our Clients Too #

We all have our favorite tools. Deliberately or not, we are inclined to advocate for those tools. In these moments when we want to gloat (C++, Go, Rust doesn’t have these problems), we should take a moment to consider whether or not we are being helpful. Seek not to be understood, but to understand.

Note that we do this to our clients too!

Our motivations aren’t always as noble as we’d like them to be. If you switch from your on-prem VMWare systems to AWS, then me and my team can be the heroes because we know that (and we don’t know how to manage your corporate network). If your Postgres indexes suck, we can switch you to Mongo and it’ll be 6 months of fun development before we get to production and find out our MongoDB indexes suck.

Seek First to Understand #

Every tool is a tradeoff. I’m not advocating for staying on legacy systems forever. But I am suggesting that if you have a problem, exhaust all available options in the current technology before branching out into a new one. If someone asks for help, listen to their specific problem and lazer focus on it, then move on to “have you considered…”.

Seek not to be understood, but to understand comes to mind.

When to Jump Ship #

Reverse the above thinking when available options on the current stack have been exhausted and any of the following (often these come in clusters)