As software engineers we tell each other to "pick the right tool for the job," but tbh,
The breadth and depth of knowledge to 1) know of all relevant alternatives, and 2) understand the meaningful differences between them, is nigh-impossible to build from on-the-job experience.
It takes an unreasonable level of interest and time to build that knowledge for a *subset* of the field.
Is there *any wonder* we collectively keep reaching for the wrong tools?
I'm thinking of infrastructure tooling, I'm thinking of frameworks, I'm thinking of libraries, I'm thinking of languages, I'm thinking of architectures,
None of the necessary knowlede is in any curriculum, nor in any of the SEO-stuffed articles you find when trying to search for answers.
It is nigh-impossible for most engineers, on most issues, to make informed decisions.
@cvennevik partially this is because we stopped building these tools in the early 00s/mid 90s.
I am not joking. Research kept going but we lost the industry knowledge of this domain. We are starting to rediscover some of it thanks to both typescript and rust community.
But it will take a long time, and there is nearly no funding. The industry forgot that we can have good tools and it actually impact output and outcomes.
@Di4na I wouldn't have thought of this angle, so thank you for bringing it up.
(Also really cool seeing you in the replies as I've really liked your writing on developer tooling and process engineering)
@yellowbrickc @cvennevik I agree, and I will add...
There is a slew of other things that you do not talk about here that exist (at least in theory and in research), which make my point :D
Effect handlers would allow us to have capabilities and DI for testing far more than we do today, but it is totally out of the realm of tools we consider.
For deployment tools, too, I know what exists in some dark corner that we can barely think about. Same for dynamic tracing. etc etc
Cecilie 🧙♀️
Thomas Depierre
Krisztina Hirth