I suspect you’ve never had a case where a manager comes to you and asks “why is this happening?” so you go through line-by-line with that person to prove that the part of the code in question is doing exactly what it was intended to do. (Which may not be what that person actually wanted for this particular case. Perhaps because the code was written for a subtly different case, or because everyone misremembers how things used to work back when that code was written.)

I do this. There’s code I’ve written five times over, because I know I’m going to need to walk through it line-by-line when things go wrong. Because it involves subtle interactions with timing of events and our customers’ custom rules.

TDD doesn’t help if the tests tell you exactly the same thing as the code, only less clearly. Mind you, they’re a big help when an example is easier to follow than an explanation.

I walk through code with people who don’t know how to program. I explain the grammar, and they can follow the logic.

Code is a form of writing. Specifically it’s technical specifications which happen to have machines in the audience. There’s no such thing as perfect code, just as there’s no perfect author or perfect writing. Nor is writing that works for one audience correct for another. But that doesn’t mean you can’t strive for perfection.

These days, kids are learning to code in elementary school. Computer science is one of the most popular college majors. People are starting to realize how code affects them. I’ve been programming professionally for over 20 years, and I’ve had a doctor with no coding experience give me advice on my algorithms. The next generation of doctors, lawyers, lawmakers, business owners, recruiters, and decision makers will be able to read code. You may be better off if they can read yours.