Another couple antipatterns I've noticed: - "We made the code twice as fast with this clever optimization" - Translation: we solved the issue badly with bad te

Another couple antipatterns I've noticed: - "We made the code twice as fast with this clever optimization" - Translation: we solved the issue badly with bad technology, thus making the simplest operations gratingly slow, our performance is 100x worse than the theoretical best possible. Now we made it only 50x worse, a triumphant achievement. This will still allow us to make several more triumphant gains, and end up with finally with something that's only 5x slower than best case. - We used a brand-name, hip library for a very specific use case - In order to solve the issue quickly, while avoiding having to understand the problem domain, we outsourced one of our core differentiators to some npm package. We made the first release in a quarter of the time, compared to doing it properly. Management was happy, because progress was fast. It kinda sucks, and there's no way to improve on it without actually investing the time and of building it ourselves. Which we won't do, but will replace library X with it's successor come a few years, making a blogpost about the stupidity of X's implementors, and praising library Y. This is a lazier parallel of the previous point, with the actual developing competencies outsourced.