We have two worlds in software. One world where everything is implemented with the best practices and work is done in the most principled way possible. This is the ideal world for nearly all software engineers. The other world is the world of reality, where everything must be judged according to its benefit. If an activity such as writing tests does not have any benefit for a particular project, it might be left out!

In every project, in addition to design discussions such as architecture design, it must be decided how much quality assurance is needed by considering the lifespan and nature of the project. Taking these factors into account, you may sometimes conclude that the best decision is writing tests, and sometimes not.

For a project that, for any reason, leaves writing tests out, if you insist on doing so, the delivery will be reduced, and your credibility as a proficient developer might be undermined. Writing tests also requires a level of knowledge and test-friendly organizational culture. If you try to enforce the idea of writing tests on other developers, not only will no one appreciate you, but you might be criticized for not aligning with the team's goals and rules. In addition, while writing tests improves the quality of your own work, doing so for a project that at most you develop ten percent of it, does not contribute effectively to the total quality of the project.

In my humble opinion, a good developer is not necessarily someone who always develops projects to the highest quality standards with the most novel technologies and a wide range of tests. A good developer is someone who finds a solution making a proper balance between business and technical requirements. This is one of the most important lessons I learned from my own mistakes. For a long period, I was making the mistake of delivering some projects with an unnecessary set of high-quality technical standards and state-of-the-art technologies but with delayed deadlines!

To summarize, In every project, the level of quality assurance needed should be decided based on factors such as project lifespan and nature. Writing tests by a single developer undoubtedly can improve the quality of his work, but it might not always be necessary and may not contribute effectively to the overall quality of the project. A good developer is someone who finds a balance between business and technical requirements, rather than always developing projects to the highest quality standards.