Here are my 2 cents, after 25 years of development in several companies. If you want to do the next developer a favor, your codebase should be simple to underst

Here are my 2 cents, after 25 years of development in several companies. If you want to do the next developer a favor, your codebase should be simple to understand. Period, that's it. Simple to understand means: 1. Don't use fancy design patterns, FP constructs, performance optimizations etc. Unless the use case specifically requires it. 2. Code should do whatever it needs to do to fulfill its business requirements. Nothing less and preferably also nothing more. 3. Readable code beats documentation: only document the 'why', and only when it is non obvious. If you find you're documenting the 'how', have a second look if you can write your code in such a way that it explains itself. 4. Explain how to build the project, run tests and whatever else is non obvious in a Readme file in your project. Documentation anywhere else, such as on Confluence, will not be maintained or read.