I’m sorry but I find this post to be a bit off, both in tone and content.

There is a notion that the only work that matters is the code as if trying to apply Derrida’s argument about a preface to the nature of code.

Or the classic story about Pablo Casals — when after playing a piece of music, was asked by an interviewer what he meant when he played the piece, and Casals’ famous response was to play the piece again.

It’s a cute, provocative, piece of rhetoric, but it’s an empty argument. You set up a straw man of predictability, and an “other” — the villain executive who believes in this insanity— and make the argument for the bazaar over the cathedral. You use this argument, as in the “actual work” comment, as a kind of technological determinist, “nerdboy” as the hero of industry narrative:

(I am the high productivity employee, and executives and everyone else — well maybye not “creatives” — are leeching off my value creation for I am the Howard Roark of Code in tune with the fundamental limits of the human mind to predicate and prognosticate! now let me do what I want and quit wasting my valuable time -oh and I'm also humble like may coding mates!)

It is way too often a cultural trait of mostly young, mostly immature, mostly male, developers. Please forgive the generalization, but I’ve seen this too often.

Communicating and creating an elegant, lean, minimalist but comprehensive, historical record in natural language (or modeling languages, or pseudo code, or boxes and arrows etc…) is not a burden — it is an obligation and mark of excellence and professionalism.

Software product development is much more than just code and automation. It is better understood as a linguistic constructivist process (potentially stochastic or “organic” to use the term you use) embedded in a context, and not an industrial throughput process (deterministic). Being able to communicate about reifications in different modalities is vital to the thinking that goes into this process. Ask yourself how you can answer the following questions — how do you know the software “is working?” “is elegant?” “solves a real problem?” unless you introduce a target against which to measure your work? — this is more than tactics.

The more people, types of people, and modalities that are escorted into the reification of the “poetic pure thought stuff” to paraphrase Brooks, of what is being built, the better off a company will be. That includes enabling and valuing the “actual work” of those “non-high performing” people riding the “high-value creating wave” of the coding heroes in your narrative. The dismissiveness in your narrative about those people in your organization is not a marker of your coding bona fides. It actually betrays a rather unhealthy view of how you value those “others” on your team.

Removing barriers so teams are functioning in healthy and productive ways across disciplines to create value is the job of excutives, and yes this is actual work as well — even if with some imagination and skill, spans of control can be flattened and extended.

And while you may be correct that too many organizations cargo cult documentation, do it in horrible, obtrusive, and counterproductive ways, more often for compliance and bike-shedding reasons than to raise capital, — it does not make the perspective you offer particularly valuable or insightful.

You may think this is a harsh reading of your post, and perhaps it is, but I genuinely hope that you are an imaginative and talented developer and that you build/have built many great things. I only took the considerable time to write this in the hope that you might reconsider and broaden your perspective.