On readable software
There is a great post circulating this week on the definition of readable code and one quote really stuck out at me:
All software gets developed under time, budget, management, requirements, and skill constraints that prevent doing anything perfectly. We should keep those constraints and limits in mind when we look at code and immediately conclude the code resists understanding, or that only fools would have produced such software.
Having moved teams internally I’m in the unusual position of being the ‘fool’ who wrote the software someone else needs to maintain and still being around to explain why it is the way that it is. This has reminded me that when reading a codebase you often only have part of the context and when you are writing how important it is to document your decisions.