[1]: http://www.se-radio.net/

[1] https://www.amazon.com/Software-Engineering-Google-Lessons-P...

- DeMarco & Lister Peopleware

- 2007. Software engineering: Barry Boehm's lifetime contributions to software development, management and research. Ed. by Richard Selby.

- Hoffman, Daniel M.; Weiss David M. (Eds.): Software Fundamentals – Collected Papers by David L. Parnas, 2001, Addison-Wesley, ISBN 0-201-70369-6.

- And his: The Design of Design. Start with Part II.

Working Effectively with Legacy Code by Michael Feathers

Our standard text for SE was Software Engineering by Ian Sommerville.

If only the Handbook of Applied Cryptography had their chapters in HTML.

As a "guy who writes code" - call me whatever you want, i could probably give myself a fancy title and get away with it, but I am one of the very successful (When compared to the 99%) people who didn't finish school but managed to get by in the tech industry very comfortably. Life is already great, perhaps I just don't deserve to get everything my way.

(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

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.

Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168

Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2

Clean coder: https://cleancoders.com/ videos

Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

Hitchhiker's Guide to Python: https://docs.python-guide.org/

Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...

John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!

Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

Dan Bader, Python Tricks: The Book: https://dbader.org/

Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...

Svilen Dobrev, various: http://www.svilendobrev.com/rabota/

> 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.

* Fundamentals of Software Engineering by Ghezzi, Jazayeri and Mandrioli

* The Practice of Programming by Kernighan & Pike.

* Code Complete by Steve Mcconnell.

* The Unix Programming Environment by Kernighan & Pike

* Advanced Unix Programming by Marc Rochkind.

* C Interfaces and Implementation by David Hanson.

* Large Scale C++ design by John Lakos

* Unix Network Programming by Richard Stevens.

The key is that while reading the above you need to "get" how the code is "structured" rather than the details. For example, how does the code for a TCP server and client "look like"? It is a kind of spatial knowledge which you can then consider as one "module" of functionality and reproduce as needed. Large Systems consist of a bunch of layered and well partitioned modules exposing simple and clean interfaces. There will also be modules which cross-cut all the functional modules like "Error-Handling", "Logging" etc. This is the core of "Software Engineering", everything else is details.

Finally, you would also need to read a book/source where you can see all of the above principles put into practice while building a non-trivial (initially not overly complex) system.

I'd suggest trying to change your "mindset" as well, building and reading supporting information at the same time. One such way is to read "SEIA" (Software Engineering for Internet Applications, Andersson, Greenspun & Grumet) which is online or in print and follow the book through ~ http://philip.greenspun.com/seia/

The book/course is easy to read and most important devoid of advocacy. The good thing is you can start now at no real cost. But it will take time and effort though.

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.