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.