“The secret of good writing is to strip every sentence to its cleanest components.”

— William Zinsser, On Writing Well

Programmers are known to often obsess over what is and is not "good code." Google is famous for its Readability process, which is seen as a role model but has some critics even inside the company (see also Software Engineering at Google and Readability: Google's Temple to Engineering Excellence). I have seen disagreements on best practices lead to lengthy, exhausting discussions in meetings or during code review, delaying important work without leading anywhere. I have also seen some colleagues, for these reasons, develop the reactionary view that insisting on clean code and enforcing a lot of software patterns are impractical for real-world projects and something that most enterprises outside Big Tech cannot afford. I recognise that an over-obsession with coding standards can be detrimental to project success, and that the requirements for code quality and maintainability should take the expected scope and lifetime of the code (one-off notebook vs. PoC vs. core infrastructure) into account. But I'm not a big fan of the "we'll fix it later" mentality.

Read more…