Comment by mjburgess

I've had some thoughts on programming practice somewhat related to Tim's role, and some on language design this morning.

I write code for others to read a lot, to explicitly teach them how to do something. This code has always been overly verbose, "decompressed" and teaches people the thought process behind a solution above being a "neat" solution. I was dragged a little reluctantly into this style, by being forced to anticipate all the ways the code may be misunderstood ahead of time -- by all the ways it was misunderstood previously. Its much less work for me to be verbose up-front, than fix misunderstandings later.

After watching and looking at some of the best systems programming code/coders -- I've come to think this is just the best way to program in general.

The latest program I wrote this way, and the quality of code is vastly higher. No abbreviations, any unusual coding practice (eg., conditional imports, using classes as namespaces rather than object templates, etc.) I noted briefly in comments to highlight it's unexpected. Any functions which are domain/app-specific have execessively long names which fully describe that step/asepct of the solution. Extensive design comments where my thinking is noted. etc.

Programs which teach their readers how to think about the solution, rather than how to understand the code -- and teach it to a "smart junior" rather than to an expert. I think this is different than literate programming, and of the maxim "code is read more than written" -- it's a specific "educational ethic": code isnt clean, or literate, or readable -- its educational.

If this is the best way for "programming in the large", then a property of programming languages follows: languages which enable the programmer to "decompress" their thoughts over many lines are preferable to ones which hinder this. This I think then explains something about the uptake of functional languages -- which resist this decompression of thoughts over lines of code. They are often sold on their conciseness -- as if a 200 line C++ ought be reduced to a 10 line F# program. This trades the wrong sort of productivity: long-lived large programs require programmers to build mental models of them far more often than they require them to add to them at-scale. A programmer self-teaches the code base more often than they write it: this isnt about reading.

This goes somewhat to the role of Tim in OP. Perhaps the right software engineering programming practice is to write code as-if you are pairing with a new programmer in the future. To verbalise everything Tim would say, already, in the code.