github linkedin
The Best X is the One You Have With You
04 April 2020
2 minutes read

You ever heard that saying in photography:

The best camera is the one you have with you

I think that’s a great rule for a lot of things. Programming, especially. We can build a lot of what-ifs, but what-ifs are the challenge of over-engineering. I spent months fawning over technology for a personal project, and the biggest takeaway was that I could visualize exactly how to do it in a language I knew very well.

  • Is it a perfect match for the product? No.
  • Do I have the time to re-engineer the whole project? Absolutely Not!

What’s the BEST X for Y?

An attitude I see a lot on teams is “What’s the best tool for X?” as if such a strong, factual answer exists. Any senior developer worth their salt knows that the things that factor into a technology decision are rarely a technical-only endeavour. When you say “Right tool for the job”, What do you mean?

  • Best fit for the team’s skills?
  • Most scalable?
  • Best maintained technology?
  • Best performing solution?
  • Easiest developer experience?
  • Easiest for sourcing new developers?

In my career, it’s very rare i’ve had full choice over the technology I work with, except in some niche greenfields scenarios. A balancing act of different concerns across a project can only result in the answer “Well, that depends!”.

Shut up and Ship 🚢

In a decision between something existing in a slightly inferior format and something never being created in the first place, I find it’s not really a choice at all.

It’s OK to ship less than everything, to compromise, if you can visualize a path forward. If the technology/tooling/language really is the thing that’s holding you back, you can revisit that later, too.

So worry less, iterate more, and spend your time thinking about the hard parts: making your product do it’s job.


Back to posts