There was a Twitter thread where someone discussed letting two people create the same proof of concept web solution. One was a very experienced developer working on their own. The other was a less experienced developer making heavy use of no-code tools, large language models, and the like. The conclusions were that the less experienced developer got a lot more done in the given time, while the only plus point listed for the experienced developer was that their solution was quite a bit cheaper to run. (It also had fewer moving parts, but that was not painted as relevant.)
Especially strange to me was a final comment about the company running the experiment being full of developers in the style of the experienced developer, and how they wanted to replace those with others more in the style and mentality of the less experienced one. The tone was that the experienced developers stubbornly insisted on writing things themselves for no good reason, keeping complexity and costs under control to such a degree that they would deliver much too little much too late and at much too high a cost.
My first thought was that the person running the experiment (who was supposedly some kind of boss ta the company) must be completely out of touch with the way the company and its customers actually work.
You do not get a hundred experienced developers insisting on keeping complexity under control and building slowly but surely for no reason. If you need to maintain things over any period of time, you start to value maintainable solutions a lot more. It does not take long for any initial speed gain from using exciting tools to be completely eclipsed by the work of elegantly gardening the code base to refine, grow new features, and keep users happy.
There is an interesting discussion to be had around going fast versus doing things well, and how to pick a good balance. It has been had many times, and the exact tools and techniques involved do not really matter. If something will fail, you want to know as soon as possible, and so it is always great to work toward getting something out quickly. And, if something succeeds, you will spend vastly longer living with whatever solutions you picked in that initial stage, which motivates thinking carefully about those choices. Build fast, and build maintainable things?
Part of the fun is that the same thing goes for frameworks and what and how they solve things. This framework is for getting things done fast! It is opinionated, we made the hard choices, and if they do not suit you then you should pick a different framework. Look how fast we can get things up and running!
Fast forward two or three major versions. One part of the framework is famously slow and creaky, and is still undergoing a bottom-up rewrite which will break backward compatibility if it ever finishes. Another part has evolved to be ever more general, and now it is not so much an opinionated framework as a general factory for opinionated frameworks. Oh, and some major ideas have come in from other successful frameworks, and it is gradually being figured out how those really fit in with everything else.
Is there even a general balance to be found? Is it not all down to knowing the tools, and the domain, and combining them in appropriate ways to produce useful things quickly, and then turning them into something which grows and adapts well over the long term.
The more you know, the faster you can build. And if you do not know? The common wisdom is that you build to find out (and then perhaps go through a painful re-write once you figure out what to build but have added too much too quickly to a foundation too unsuitable?)
Perhaps we are simply over-valuing individual decisions and short time horizons? What if the truth is that the steps in themselves do not really matter as long as the direction is good enough? Sure, it is easy to see the folly in the true extremes, but how often does anyone really head for one of those? Most real projects live deep in the grey zone, where it can often seem as if going more extreme in almost any direction would produce outsize results, when in truth the moment would look dramatic because the direction shifted, even if the results over time remain constant.
Am I going anywhere with this? No. I am paddling around in the grey zone, just like everyone else. But I will be curious to see if all these words could gel into something over time if I keep thinking about them.