3 Useful anti-patterns

This chapter covers

Known bad practices that can be put to good use
Anti-patterns that are, in fact, useful
Identifying when to use a best practice versus its evil twin

Programming literature is full of best practices and design patterns. Some of them even seem indisputable and provoke people to give you the side-eye if you argue about them. They eventually turn into dogmas and are rarely questioned. Once in a while, someone writes a blog post about one, and if their article gets the approval of the Hacker News¹ community, it can be accepted as valid criticism and can open a door for new ideas. Otherwise, you can’t even discuss them. If I had to send a single message to the world of programming, it would be to question all the things that are taught to you—their usefulness, their reason, their gain, and their cost.

Dogmas, immutable laws, create blind spots for us, and their size grows the longer we stick to them. Those blind spots can obscure some useful techniques that can even be more useful for certain use cases.

3.1 If it ain’t broke, break it

3.1.1 Facing code rigidity

3.1.2 Move fast, break things

3.1.3 Respecting boundaries

3.1.4 Isolating common functionality

3.1.5 Example web page

3.1.6 Leave no debt behind

3.2 Write it from scratch

3.2.1 Erase and rewrite

3.3 Fix it, even if it ain’t broke

3.3.1 Race toward the future

3.3.2 Cleanliness is next to codeliness

3.4 Do repeat yourself

3.4.1 Reuse or copy?