A Portrait of the Coder as an Old Man

I've been thinking quite a bit about being a older coder.  I've come to the realization that, like most other professions or activities, as we age, we need to make accommodations.

For example, as we age, the short term memory begins to fade.  Where once I could reliably recall the names and type details of hundreds of the variables, functions, and methods I've touched on a large task, now I can only reliably remember a couple dozen.  As a young man, I could focus on whatever function I was modifying, using memory and recall should I need to add a function call or variable reference.  Now I do spend a lot of time tap dancing through code, always referencing headers and declarations, with dozens of files open at any given moment.

On the flip side, the long term memory, now so richly loaded with associations, can get bogged down in those associations.  Every module or algorithm brings to mind another module or algorithm.  This is like that is like this is like that.  Which is very useful given that there is nothing new under the sun, but sometimes there is something new that needs to be considered on its own merits.

Also, there is the problem of irascibility.

I have spend almost all of my professional life coding in subsets of C.  Various embedded or safe or DO-178B restrictions to C.

C, in particular, has two problems for the old coder.

First is the problem of irascibility.

C is very simple with a minimal library.  I remember the first time I coded a doubly-linked list or a binary tree.  So satisfying to get this concept and see it function.  It is fun the first time, or the second.  But after 30 years, I never again want to code a doubly-linked list, a sort, a hash map, a binary tree, a dispatcher, a parser, a lexer, a matrix pseudoclass, a polynomial solver, or a Kalman filter.  It is just no fun anymore.

Second is the problem of verbosity.

Since I know I no longer have an infallible, photographic recall of an entire codebase, it helps to be able to have as much code on the screen at any given moment: to be able to see as much as possible of what I am doing.  And C, in particular, is so verbose that it restricts the amount of meaning I can throw up on any given screen.  C so often oscillates between being information dense and having a paucity of information per line.

So, then, coding as an old man...

• I need my language and tools to help me remember details of variables, functions, and methods.  And I need those tools to help me remember in a way that doesn't destroy my flow.
• I need my language and tools to let me see as much of what I am doing as possible.
• I need my language and tools to not require me to re-code or re-integrate fundamental algorithms that are no longer entertaining.
• I need my language and tools to help me determine if a code block is or is not a fundamental algorithm.  If it is, I want to use that fundamental algorithm.

Let's imagine, for a second, the properties of a theoretical programming language created for older coders. Such a theoretical language would be designed from the ground to play well with tools.  There should be nothing in the grammar of the language that would prevent tools from autocompleting or suggesting a given declaration.  The scoping and context rules should not have the sort of ambiguity that prevents effective tooling.  And compilation errors should be flagged immediately.

Also such a language should have a consistent level of information density, so that a screenful of text is sufficient to display a "unit" of code.

I don't often stray too far from the C-language family.  To be honest, C# is pretty good as an old man language. But, I've been trying to brush up on my C++17.

#include 〈algorithm〉 is pretty cool.