The longer I spend engineering, the more I just want to get the job done and get it over with. I've built, and will continue to build, strongly-opinionated fram

The longer I spend engineering, the more I just want to get the job done and get it over with. I've built, and will continue to build, strongly-opinionated frameworks and platforms based on my experience. But this week's silver bullet is next week's anti-pattern: mostly because of a misunderstanding of when, how, and where to apply design patterns. Truthfully, it's increasingly my opinion that design patterns (and by extension, anti-patterns) only exist in the context of focused, internally consistent systems architected by a small group of individuals and not a committee. Rails, especially early on, is a great example. Actually -- a huge chunk of programming languages are built this way. The web, however, is designed by committee. With this framing, "avoiding margins" works for the way Max builds design systems -- and from what I know, he's very talented and the team(s) that work with him should adhere to the systems he constructs. I'd love to see an implementation of an entire framework / design system that avoids margins -- something like Tailwind CSS. I do not, however, really believe this is broadly applicable advice. Most people are just trying to ship something that looks nice, and margins can be overwritten and adjusted easily. NOTE: I have components I've written that have margins I have to overwrite nearly universally, but can't remove because of other UIs relying on the margin behavior. So I understand where the argument comes from. It's just -- I'd have a hard time if anybody tried to pick a bone with a software engineer on the team about the use of a margin if the initial intention was good / legitimate.