[PaulRobinson]

One of the problems I have with it is the advice comes down to unhelpful abstractions that tries to wave away mechanical empathy.

I spent years writing Ruby and found clean code OK, but preferred Sandi Metz’s writing. Then I started doing some Go and Bill Kennedy made me think about mechanical empathy more. Recently I’ve been diving back into my old haunt of C, particularly more modern C idioms and the C23 standard as I need very fine grained control for latency and memory efficiency reasons for the apps I’m writing (in a very different space to where I worked in Ruby). It’s kind of blown away a lot of the advice from clean code for me.

The thing you’re programming has a CPU with registers. There’s a stack. There’s a heap. The choices you make choose how those things are used by the language implementation you’re using. Languages and methods that try to pretend none of that is happening can lead to very inefficient code that makes everyone sad.

Yes, your code needs to be readable. It has to be maintainable, but the clean code way of doing things doesn’t seem to do that very well AND introduces patterns that can make it hard for compilers and interpreters to optimise.