Two books about to be published in this genre which I am excited about:

(1) Software Development Pearls: Lessons from Fifty Years of Software Experience (Karl Weigers). I enjoyed his books on Requirements and Software Engineering Culture

This zinger really applies to my work place "Lesson #7. The cost of recording knowledge is small compared to the cost of acquiring knowledge"

(2) Code That Fits in Your Head: Heuristics for Software Engineering (Mark Seemann). His previous book on Dependency Injection was good

Yes. That first paper is Boehm, Barry W., "Software Engineering", IEEE Transactions on Computers, December 1976, pp. 1226-1241, vol. 25
DOI Bookmark: 10.1109/TC.1976.1674590, https://www.computer.org/csdl/journal/tc/1976/12/01674590/13... At the time Barry W. Boehm was at the TRW Systems and Energy Group.

The Boehm paper says "Fig. 3 shows a summary of current experience at IBM[4], GTE[5], and TRW on the relative cost of correcting software errors as a function of the phase in which they are corrected." and indeed figure 3 (page 1228) shows exponential growth. It only shows averages or ranges for each data source, and that's a legitimate critique. That said, it does show them for multiple companies, and then presents a trend line that plausibly follows from the data provided. Boehm has a good reputation, I expect that this really was a reasonable observation from real data.

It's legitimate to question whether or not that is still true. Computer "science" is notorious for having almost no science - experiments are almost non-existent. I would love to see this & many other experiments conducted to see what's true today.

Or read the first and second paragraph?

> When I first picked up Software Engineering at Google I thought it was another one of those FAANG books full of lessons that make no sense at human scale. I was surprised, the lessons apply to teams as small as 5.

> This is a "good shit stays" recap. The lessons that stick with you a few weeks after reading.

> If you see those things as "the boring bits" that you don't want to do then you're not a developer. You're a hacker.

This point parallels the distinction made in the Software Engineering at Google flamingo book between programming and engineering. Engineering comprises the tools and processes to maintain software over time (this is a rough paraphrase), of which docs, for example, is essential.

So to use their language with your point: this sounds purely like programming and perhaps not engineering.