21 Counterproductive Practices That Can Destroy a Software Team

Recently several readers asked how to become an excellent programmer, and the author, "Yang Ge," shares a sarcastic yet insightful list of practices that can cripple a development team.

1. Reinventing the wheel – Even when mature libraries exist, some developers insist on building their own solutions, believing it improves architecture and prevents being replaced.

2. Overusing design patterns – Applying complex patterns like DDD for no real benefit, adding unnecessary layers and “cool” but impractical designs.

3. Skipping gradual rollout (gray release) – Rejecting incremental deployment and validation, claiming confidence in a full‑scale launch without testing.

4. Ignoring rollback plans – Believing that luck alone will keep services stable, refusing to prepare for failures.

5. Not understanding the business – Dismissing the need to know domain logic, focusing solely on technology.

6. Excessive remote calls – Favoring complex inter‑process communication (sockets, pipes, shared memory) over simple local calls to showcase skill.

7. Not separating environments – Merging development, testing, staging, and production into a single setup to speed up delivery.

8. Low cohesion, high coupling – Promoting tightly coupled code as a sign of power, despite the loss of productivity.

9. Ignoring idempotency – Expecting the backend to handle duplicate requests without proper safeguards, blaming the frontend for failures.

10. Not setting timeouts – Assuming the system will always respond quickly, ignoring the need for timeout handling.

11. Not implementing retries – Claiming that code should succeed on the first try, refusing to add retry logic.

12. Skipping monitoring and alerts – Dismissing the importance of observability, arguing that developers are already overworked.

13. No database design – Treating every data store as a single table, ignoring proper schema planning.

14. Skipping performance testing – Viewing load testing as unnecessary effort that only wastes time.

15. Blind for‑loops – Ignoring algorithmic complexity, assuming modern hardware makes inefficiency irrelevant.

16. No data backups – Trusting that servers will never lose data, avoiding backup procedures.

17. No permission management – Granting everyone super‑user rights, believing it fosters freedom.

18. Refusing microservices – Consolidating everything into a single service to avoid operational complexity.

19. No code scanning – Relying on personal confidence instead of automated code review tools.

20. Ignoring official documentation – Claiming language barriers or overconfidence make docs unnecessary.

21. No framework design – Dismissing structured architecture in favor of ad‑hoc coding.

The author warns that even a few of these habits can destroy a technical team, urging programmers to pursue excellence and avoid these pitfalls.