Last week we ran into the perfect example of how utils-based code will smack you over the face at the worst moment. So much time wasted

Swizec's platform provides resources for developers, covering a diverse range of topics such as programming languages, web development frameworks, data visualization techniques, and software engineering best practices. Through tutorials, guides, and coding challenges, Swizec offers hands-on learning experiences and practical insights for developers at all skill levels. Readers can explore  technologies, industry trends, and software development methodologies to enhance their technical proficiency and advance their careers in the tech industry. Additionally, Swizec shares personal anecdotes, career advice, and productivity tips to inspire and motivate aspiring developers on their journey of continuous learning and professional growth.

swizec.com

Utils-based code organization creates circular import problems that break applications unexpectedly. When payment utils depend on email utils and vice versa, Python cannot resolve the circular dependencies. The solution is vertical module organization based on domain context rather than technical function - group everything about payments (including emails) in a payment module, while keeping low-level operations like email sending in separate atomic libraries.

Why utils are bad, an example

Learned something new? Read more Software Engineering Lessons from Production

Always read the comments first before you read the article it will save you time

This article reminded me of an AI solution to a complex problem in which I turn up where are started before using AI.

Utils should never know anything about the domain specific logic. It should stay small and solve only a problem, never nested or combined logic.

Better title “When we called something by the wrong name and implemented it anyway”… What the author describes as &quot;util&quot;s are actually just domains as a sort of false abstraction and doesn’t really meet the purpose of “utils”. This starts as an architectural problem from the outset which is probably why it takes an architectural approach to dig them out of it. Probably could have solved this a lot of ways, depending on how large the product is but may have to be as complicated as having a payment domain, email domain, and content domain. In that path the content might be as simple as email templates in-app but could call out to email authoring somewhere else, and the payment domain would have to know which email template it was using but all of that information would be passed to the email domain to stitch it together and do email-y things (even with transactional emails).

i agree with the post. some may not understand because “utils” have a wide range of interpretations. but think about a codebase that has little to no organization, and everything is inside hundreds of utils files with some 50-100 lines each file. it’s hard to navigate and even harder to find if what you want already exists.
it’s totally fine to have good package management and have “utils” folders in the proper places. but “everything utils” it’s a nightmare.