Can 100% confirm this from own experience! I've been the most productive (by far more than "10x") using my own set of tools, which have been created & refined by continuous praxis (dogfooding) and employed for hundreds of use cases over many years, and also partially followed me across different programming languages.

Unfortunately, many sectors of the software industry have succumbed to a formulaic paint-by-numbers approach to general "problem solving", which almost always exclusively relies on a handful of large frameworks, and with very little appetite remaining for any alternative approaches (maybe even more efficient and easier to maintain)... It's not just technology choices, but design processes/disciplines themselves too. Monopolies & monocultures everywhere, willingly adopted and encouraged, justified via more shallow learning curves, oversimplifications/mainstreaming, supposedly better hiring/career options and other self-selected network effects...

I noticed the software industry had already gotten into a rut ~10-15 years ago, way before the agentic vibe coding steamroller... Maybe due to overeager (and partially uninformed) adoption of design patterns, maybe due to the lack of caution understanding the impacts of introducing increasing amounts of complexity and dependencies, maybe because of the shortening attention spans caused by sprint-based work cultures (which only prioritize short-term goals) and the aforementioned unchallenged routine use of conceptual, architectural and code frameworks... Probably it's all of the above (and more)...

In short, had more industry players invested long-term into tailored tool building as part of their business, I think vibe coding would have had a lot less impact than it had so far. Defenders of LLM coding are frequently claiming the models are helping them to severely cut down on boilerplate and configuration tasks. This is unarguably a big win indeed! However, I also think the reason why so much boilerplate exists in the first place is exactly because of the points I listed above.

Using ye olde "hammer in need of nails" metaphor, so many orgs are attempting to solve all their tasks/projects via a handful of preexisting products/frameworks (and/or LLMs trained on materials which are statistically biased to produce better generated outcomes for these frameworks, a separate discussion).

The industry at large has been reduced to monolithic solutions, with layers and layers of customization via configuration piled on top. It's non-scalable & non-optimizable structurally and it's the wrong way to achieve/improve efficiency (or even proficiency) in your actual problem domains. It's also incomparable to the efficiency gains possible when designing & using a truly custom set of tools, including actually designing for bottom-up re-use & re-composition.

(Apologies for the wall of words)

#Software #Productivity #Architecture #Design #Frameworks #Monopoly

@ewen Maybe it's a good moment to bring out some classic quotes again:

"We make our tools and then they shape us."
(not giving attribution because I've seen far too many conflicting sources for it)

"The limits of my language means the limits of my world."
— Ludwig Wittgenstein

Also this one:

"You don't need tools. You need techniques."
(here I actually don't know the source)

All of them, but especially the latter two, have been very influential on my tool-building journey and design philosophy in general. Tools are concrete instantiations of concepts, techniques, but techniques themselves are much more important, more transferable and more valuable to learn, to adopt and to internalize.

Tools are replaceable, or at least they should be.

In almost every other field of human endeavor, tools have mostly been replaceable and skills learned (aka techniques) are directly transferable. Only when it comes to software have we changed this behavior to fully bind large parts of our problem solving skills & approaches, and in many cases, our entire livelihoods, to a handful of increasingly monopolistic tool vendors, whose only interest is to extract value, bind us to their tooling, their platforms and their network effects.

I've seen this in all parts of the creative and tech industries: Help and condition people to become a power users/operators (or "thought leaders") in these insular systems, support and entice them with a few extra morsels thrown here and there to select people (e.g. sponsorship deals), dangle career opportunities, invitations to conferences/events where they sing praise to the platform lords and opportunities. In the end, this "community engagement" is all a form of marketing for these providers, platform-based nepotism, connections, revolving doors, more than about the actual work produced or transferable skills obtained.

For the longest time, I found this behavior especially predominant and so very alienating in the "creative industries", which just seemingly can't get enough of this model! Rather than investing time & effort into helping shape and co-create ownable tools and transferrable techniques themselves, to experiment and create with techniques "outside the box", for the longest time the de-facto behavior has always been to become a "company man"-type person/expert.

Narrow field experts, consultants and "platform wars" everywhere, for as long as I can remember: AtariXL vs. C64, ST vs Amiga, Flash vs. Director, Cubase vs Protools vs Ableton, Adobe vs Affinity, Houdini vs. Alias vs. Blender, Light Room vs. Dark Table, Processing vs. OpenFrameworks vs. Cinder, React vs Angular vs. Vue, C vs Rust vs Zig etc.

In some sense it doesn't even matter if these are closed or open source platforms/providers. Entire disciplines/sectors are tied up in monolithic & monopolistic tools and the streamlined visions/philosophies of their purveyors.

Every creative idea and solution is mostly approached & judged through the lenses of these tools and their capabilities. For many even only unconsciously so. Auto-pilot mode engaged.

Almost every one of these discipline-defining tools has turned into super complex bloatware, deemed necessary to establish and maintain monopoly status, cover all bases. And even though these tools have become so huge and do afford a vast spectrum of creative expressions, I've been finding it extremely disturbing and alienating that, as a social group, especially "creative" professionals are exhibiting such strong consumerist behaviors and just aren't more interested in questioning and shaping these workflows, these tools and possibilities/options themselves, seemingly unaware (or uncaring) about that second part of the first quote above:

"...and then they shape us"

#ToolMaking #Creativity #Tech #Monopolies #Platform #Behavior #Quote