The worst programmer I know

That should make you even better equipped to design simple interfaces that require as little depth of understanding as possible from the next person.

Similarly I've happily spent my couple of years with functional purity and higher-level types in academic languages - function signatures sometimes orders of magnitude longer than the implementation itself - yet I dip into those depths only as necessary and try to keep my TypeScript interfaces as "stupid" as I can get away with without compromising on semantics. Enums are too fancy for me. I try to keep state at minimum but there's a 'let' every few thousand lines or so.

And all that venturing into lower-level concurrent C++, agent systems, parallel programming, erlang? You ain't gonna know about any of that looking at my concurrent Rust.

> One of the benefits of working at the direction of my own muse.

Oh, well, what I'm writing above is from the point of code meant for collaboration - either open source or professionally. If you're coding for yourself only, or in academia, by all means stop trying to please the crowd and start cranking out some poetry!

And yes . . . I do code.

so if you automate trivial predictable work (for example by making a CRUD app generator), you're moving to non-trivial software territory with costs unknown (as you said, you can't estimate), potentially very high

It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand.

This is what is the problem with modern-day Management/Leadership and eloquently pointed out by David Graeber(Bullshit Jobs - https://en.wikipedia.org/wiki/Bullshit_Jobs) and Jeffrey Pfeffer(Leadership BS - https://jeffreypfeffer.com/books/leadership-bs-fixing-workpl...).

I highly recommend reading this speech by David Packard (one of the founders of Silicon Valley via HP) to new Managers given in 1960 and note how relevant it is for all companies today - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...

Relevant Excerpt:

Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.