Almost all of the listed "antipatterns" are things that are bad by definition. "Don't do the thing too much or too little, do the right amount" is not a useful recommendation.
My favourite system to work on is one that I understand.<p>And everyone refactors to their own understanding and intuition.<p>And my intuition or understanding might not be identical or as advanced or as simple or insightful as yours. (EDIT: Your understanding that things are SIMPLE might be more advanced than mine, so I don't really understand it as much as you do.)<p>So we have taste in software.<p>I would rather not maintain a system that was built on quicksand, where dependencies cannot be upgraded without breaking anything.<p>One person's super elegant architecture is Not Understandable™ to someone else.
I am very susceptible to the ‘Misapplied Genericity’ anti-pattern. When given a problem, my default approach seems to be building a solution which ends up looking more like a framework that allows you then to build the solution in it. For example - if I were creating a metrics dashboard, I would end up building a dashboard builder which I could then create my metrics dashboard in, rather than just ‘hardcoding’ the dashboard I need right now. Something I need to work on!
This reads like barely chatGPT-quality output and also appears to be an SEO ploy from the domain name on down.<p>One of the anti patterns is "making the system too complicated" Insightful!
Apart from the patterns that are obviously good or bad by definition, most of the patterns and architecture decisions have their pros and cons, and the focus is on understanding, discussing those tradeoffs, and going with tradeoffs that a team / company prefers to deal with. Monolith vs. microservices, synchronous vs. asynchronous communications, small events vs. fat events - the list can go on, there are no silver bullets or clearly right choices.
First example is not clear cut at all.<p>The project sounds successful overall to me. Yes, they had to do more than they thought going in. That describes most engineering efforts.<p>Does the author think that operating system API churn just won't affect native somehow? Or be improved when even more of your application surface area is in the native space?
A list of 'do-not' works for tasks that bottom out in science and the laws of physics. Like woodworking or fusion physics.<p>Thinking about coding lacks a connection to a scientific terminus point. Under the hood it's all binary and devs use a performance mindset. Making a list of prohibitions doesn't fit.