Kerrick

I just finished Domain-Driven Transformation by Lilienthal & Schwentner. It's the book I've been seeking for years.

I'm currently reading More Fearless Change by Manns & Rising. I've always enjoyed being a change agent, and I would've been more effective if I'd read this book a decade ago.

Next up, I plan to read Facilitating Software Architecture by Harmel-Law.

Oh, and every day or two I read aloud a chapter of Magic and Meaning Expanded by Burger & Neale to my wife. We're both magicians and big fans of Eugene Burger's work.

Other translations keep Zinsser's preferred lack of fuzz but avoid using "is ... to" for possession.

For example, the Lexham English Bible:

> I looked again and saw under the sun that the race does not belong to the swift, the battle does not belong to the mighty, food does not belong to the wise, wealth does not belong to the intelligent, and success does not belong to the skillful, for time and chance befalls all of them.

For some things, good enough is good enough. For many things, it is not (and neither are random posts on the internet). Before Web 2.0, it was similar to whether I'd trust some random person on the street with it versus going and looking it up in Encyclopaedia Britannica, or the American Heritage Dictionary, or Roget's Thesaurus, or the UC Davis Book of Dogs, or the Cornell Book of Cats, or the Merck Manual, or even the World Almanac or Bartlett’s Quotations if I was feeling petty.

No, the sense had nothing to do with the content and everything to do with the context. Perfect grammar and writing style were never enough to get me to trust an anonymous forum post or unknown bloggers post for certain topics like health advice. Sloppy grammar and writing style were never a deterrent for me believing them for other kinds of topics like where to check on the HVAC system to find the sticker. I think the line could more accurately be described as the level of risk if it's wrong.

I have a distinct line between when I'm willing to believe an LLM's output and when I'm not: whether I would believe the same thing from an anonymous Internet forum post or a blogger I don't know. Those posts are not unlikely to be misinformed, biased, lies, or otherwise untrustworthy. And yet, I spent plenty of years honing a sense of when they were good enough for certain things.

You can handwrite more than just your first draft. It was common before the proliferation of computers to handwrite early drafts in pencil, and then handwrite the final manuscript with ink.

Most blu-rays are 1080p, not 4K. The latter gets marketed as "UHD" and sold in a black case, to contrast the blue case of traditional FHD blu-rays.

I suspect that vibe coders who hit a wall need the same thing that programmers from 2003 who hit a wall needed. Talk to the business people, get an understanding of their domain and the problem at hand, and model that as a series of anthropomorphic objects that encode the business rules in the language that the domain experts already used (tweaked by the need for disambiguation and clarity). Back in the day, this was software design, a distinct skill (and often job!) from computer programming.

I'd love to read your book, if you write it. Anybody who's talked to a thousand people trying to solve the same problems will have an amazing perspective and a lot to teach.

That wall was detailed in 2003 in Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, Chapter Four, "Smart UI Anti-Pattern." The context is the same, the problem is the same, the solution is the same. Even the advantages and disadvantages are the same as what you see in vibe-coded projects.

> A project needs to deliver simple functionality, dominated by data entry and display, with few business rules. Staff is not composed of advanced object modelers.

> [...] Simple projects come with short time lines and modest expectations. Long before the team completes the assigned task, much less demonstrates the exciting possibilities of its approach, the project will have been canceled. [...] And in the end, if they do surmount these challenges, they will have produced a simple system. Rich capabilities were never requested.

> Therefore, when circumstances warrant:

> Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available.

> [...] Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common. Considering it here helps us understand why we need to separate application from domain and, importantly, when we might not want to.

> Advantages: Productivity is high and immediate for simple applications; Less capable developers can work this way with little training; Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests; Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately; Expanding the system with additional, simple behavior can be easy; Relational databases work well and provide integration at the data level; 4GL tools work well; When applications are handed off, maintenance programmers will be able to quickly redo portions they can’t figure out, because the effects of the changes should be localized to each particular UI.

> Disadvantages: Integration of applications is difficult except through the database; There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply; Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options; Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.

> [...] Remember, one of the consequences of this pattern is that you can’t migrate to another design approach except by replacing entire applications. [...] Don’t bother hedging your bet. Just using a flexible language doesn’t create a flexible system, but it may well produce an expensive one.