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 @Di4na Exactly this. It’s also both humbling and enlightening to realise that our field is young and at best at the stage of medieval alchemists before the discovery of thermodynamics.
It will still take years, perhaps even generations, to formalise, distill and simplify the knowledge we accumulate to something comparable to the laws of physics. In the meantime, we all just have to learn the craft, practice the patterns and build up a gut feeling of what works, when it works, and what doesn’t.
@yellowbrickc @Di4na @cvennevik indeed! As @trondhjort has explored in length, development is a socio-technical skill.
As such, in most of the domains worth discussing (occupying the 2 ½ last quadrants of Cynefin), we are dealing with such advanced systems that it’s very difficult to prescribe cause and effect.
Software development is comparable in age and maturity of fields such as psychology and economics. All of them are about exploring and making sense of such complex systems that whatever enlightenments and knowledge we have uncovered, it’s only the first layer of fresh snow on the tip of the iceberg.
It’s hard to obtain the perspective required to view the current state of affairs as the minuscule steps of progress they actually are, instead of self-elevating us to the status of resident royal astrologers.
It’s difficult, but I think this perspective and the humility it imbues is a very important skill to pursue — for all of the mentioned fields (especially economics).
Cecilie 🧙♀️
Thomas Depierre
Krisztina Hirth
Asbjørn Ulsberg