We have all probably been in a situation where
Code quality is compromised
We were in a rush, we decide that a working mess is better than nothing, nobody cared to keep code up-to-date, we were tired of that codebase, we tried to do too much at once, we were thinking of the next shinny project, there was some external pressure, etc. And usually we have an excuse for doing it: it's only this time, requirements changed, we will fix it later (later equals never).
Don't take me wrong, these things are normal so it should be normal to take the time to make it right. Otherwise, as time goes by code quality decreases and features take longer to implement. We engineers don't dependent on anyone to actually have clean code, "the same way that managers defend schedule and requirements with passion, our job is to defend the code with equal passion".
Code is about communication
Code is about communicating what is our understanding of the requirements and it's about communicating with the people that will read that code in the future. Communication is a big challenge because we all perceive and understand things differently.
So to tackle this the industry, over the past years, has been coming up with good practices that enables us to steer in the right direction. Did you notice the use of "good practices" instead of "best practices"? This is because these ideas "don't insist on perfection, only on honesty of doing the best we can".
The posts in the list below dive into some aspects that contribute to good code. They aim to be technology agnostic, even though the examples use Scala.
This series of posts was mostly based on the book Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin (aka Uncle Bob).