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

working software over comprehensive documentation;

Good code documents itself.

But there’s a lot of context outside the code that informs it. There’s architecture and design decisions about which language to use, about whether it’s micro services, monoliths, containers, clouds, or mobile apps.

There’s legal frameworks and security certifications.

Code determines how. Tests determine the what. But documentation tells you why and when. Documentation supports future you or the next team member to understand what the reasoning behind that code was. It gives your present self grace for what you know now and don’t know yet.

Document the requirements in just enough detail, but document the decisions in depth. Working software, that’s suitably readable, is the best way to describe what it does. But understanding how that code came to be has a value you only understand after you forget how it came to be.

Document why you built this, but not that. What was the experiment? What was the context? Is it time to experiment again? Is it time to chalk the experiment up to experience and move on?

Be nice to yourself. Comprehensively document decisions.
#agile #code #software #teams