"On the criteria to be used in decomposing systems into modules" (1972) - because the core principles of modularity haven't changed [https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria...]

"The Mythical Man Month" (1975) - because human nature hasn't changed [https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...]

"The History of Fortran I, II, and III" (1979) - because this historical piece by the author of the first high level language brings home the core principles of language design [https://archive.org/details/history-of-fortran]

"The Unix Programming Environment" (1984) - because the core basics of the command line haven't changed [https://www.amazon.com/Unix-Programming-Environment-Prentice...]

"Reflections on Trusting Trust" (1984) - because the basic concepts of software security haven't changed [https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...]

"The Rise of Worse is Better" (1991) - because many of the tradeoffs to be made when designing systems haven't changed [https://www.jwz.org/doc/worse-is-better.html]

"The Art of Doing Science and Engineering: Learning to learn" (1996) - because the core principles that drive innovation haven't changed [https://www.youtube.com/playlist?list=PL2FF649D0C4407B30] [https://www.amazon.com/Art-Doing-Science-Engineering-Learnin...]

"xv6" (an x86 version of Lion's Commentary, 1996) - because core OS concepts haven't changed [https://pdos.csail.mit.edu/6.828/2011/xv6/xv6-rev6.pdf] [https://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf]

I recommend reading The Mythical Man Month[1] to anyone interested in proper SWE project management. There are so many wannabe managers out there that will just through more people at a project which is slowing down.

To quote the book: "Adding manpower to a late software project, makes it later". There's some really good stuff in there, even for those of us that are less interested in management.

[1]: https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

Mythical Man-Month, Fred Brooks [0]. Very informative series of essays on his experiences and lessons learned with IBM. If nothing else, helps to properly frame my expectations on projects with respect to resources needed to properly coordinate with others, and the pros and cons of adding people to projects at different stages (and in different roles).

Getting Things Done, David Allen [1]. Useful toolkit for getting things out of my head and onto paper (or org-mode or OmniFocus) so that I can properly focus and prioritize my time on the things I need to get done.

Communicating Sequential Processes, C.A.R. Hoare [2]. Strongly influenced the way I think about programs in general, but specifically in the embedded field where I work. (NB: I've not actually read or worked through the full text, but mainly taken what was needed to properly communicate ideas in my designs or to analyze designs and systems others have produced. This is a task for myself for early next year.)

Moonwalking with Einstein, Joshua Foer [3]. I've always had a good memory, I actually picked this up to give to a girlfriend who had a terrible memory and read it in a couple days before giving it to her (she was out of town when it arrived). Helped to explain methods that I'd somehow developed over the years, and gave me concepts and a better understanding of other methods of memory acquisition (for either short or long term purposes). If you really want to improve your memory, there are probably better resources to learn specific techniques, but this was an informative and entertaining overview. WRT work, we have to keep large systems in our minds all the time, and potentially dozens of different systems written in different languages. Memory is critical for this, even if it's just the memory of where to find the information and not the information itself.

Fluent Forever, Gabriel Wyner [4]. This one is my current read. Goes back to Moonwalking with Einstein. While the book is itself about language acquisition, it's actually given me quite a bit to think about with respect to general learning and memory acquisition (in this case, specifically for long term retention and recall). We have a couple training programs (we need more) for our new hires on development and testing. There are some concepts in here and in related readings that I think would greatly improve how we teach these folks what they need to know and in a way that would improve their retention of that information. We have a lot of people retiring in the next 1-3 years, so this is actually quite critical right now, though management is quite lackadaisical about it.

[0] https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

[1] https://www.amazon.com/Getting-Things-Done-Stress-Free-Produ...

[2] http://usingcsp.com/cspbook.pdf

[3] https://www.amazon.com/Moonwalking-Einstein-Science-Remember...

[4] https://www.amazon.com/Fluent-Forever-Learn-Language-Forget/...

=========================================

EDITS:

The Toyota Way, Jeffrey Liker [5]. I grokked Lean from this. Hardware focused, but the concepts can be (and have been) generalized to other process focused fields. This has helped with understanding what business processes really need to be codified, what feedback mechanisms need to be present for improvement, the criticality of bottom-up feedback and improvement (employee investment in the company/product cannot be overvalued if you want quality and good craftsmanship).

The Little Schemer, Friedman & Felleisen [6]. Going back to the comments on Fluent Forever. The structure of this is fantastic for conveying and helping students retain information. The Socratic method is very useful, and structuring courses and introductory material in this format is useful, this happened to be my introduction to it (well, I'd heard it before, but my first time really encountering it in practice). It's a useful tool for solo-study of a topic (pose your own questions and construct answers), and as a method of guiding someone to a conclusion or better understanding. Also useful in debugging software or decoding software you didn't write, after a fashion.

[5] https://www.amazon.com/Toyota-Way-Management-Principles-Manu...

[6] https://mitpress.mit.edu/books/little-schemer

Or The Mythical Man Month ( https://www.amazon.com/Mythical-Man-Month-Software-Engineeri... )

Honestly I'm kinda surprised that didn't come up sooner...but only half-surprised.

I second that observation. I wish the manager at my day job read ANYTHING, at the very least some informercial-laden industry publication.

In my case, I'd like him to read Fred Brooks' "The Mythical Man-Month", to make him understand how a programming system costs a lot more than a simple module.

Summary: http://javatroopers.com/Mythical_Man_Month.html

In second place, I'd place "Peopleware", so he'd understand the importance of communications, and how the current office arrangement is losing the company a lot of money:

Summary: http://javatroopers.com/Peopleware.html

Amazon link to both:

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

http://www.amazon.com/Peopleware-Productive-Projects-Second-...

I think reading this book[1] is even more important than learning to use a keyboard (and mouse) with the intention of creating software or any complex system.

Knowing your limits is one thing, but understanding why/how they are being manipulated by outside forces (e.g. overestimating ability) is another. And how to counter those forces is also included in these pages.

Thank's for the sanity and well-managed project advice Fred!

[1] http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

Joe Armstrong's paper on the history of Erlang (of which he was one of the authors) is superb (though it's less about corporate culture than about the language): http://cobweb.cs.uga.edu/~maria/classes/4500-Spring-2010/pap...

There's The Mythical Man-Month: http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

Showstopper, the book about the development of Windows NT, is great: http://www.amazon.com/Show-Stopper-Breakneck-Generation-Micr...

Indeed, the history of the development of very large software systems has been littered with disasters. Don't people read The Mythical Man-Month any more?

http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

I'm a huge believer in going back to primary texts, and understanding where ideas came from. If you've liked a book, read the books it references (repeat). I also feel like book recommendations often oversample recent writings, which are probably great, but it's easy to forget about the generations of books that have come before that may be just as relevant today (The Mythical Man Month is a ready example). I approach the reading I do for fun the same way, Google a list of "classics" and check for things I haven't read.

My go to recommendations:

http://www.amazon.com/Structure-Scientific-Revolutions-50th-... - The Structure of Scientific Revolutions, Thomas Kuhn, (1996)

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master... - The Pragmatic Programmer, Andrew Hunt and David Thomas (1999)

Things I've liked in the last 6 months:

http://www.amazon.com/How-Measure-Anything-Intangibles-Busin... - How to Measure Anything, Douglas Hubbard (2007)

http://www.amazon.com/Mythical-Man-Month-Software-Engineerin... - Mythical Man Month: Essays in Software Engineering, Frederick Brooks Jr. (1975, but get the 1995 version)

http://www.amazon.com/Good-Great-Some-Companies-Others/dp/00... - Good To Great, Jim Collins (2001)

Next on my reading list (and I'm really excited about it):

http://www.amazon.com/Best-Interface-No-brilliant-technology... - The Best Interface is No Interface, Golden Krishna (2015)

If you're interested in this topic, might I recommend:

No Silver Bullet: Essence and Accidents of Software Engineering, Frederick Brooks (1987) - http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...

No Silver Bullet Refired, Frederick Brooks (1995)

Both can be found (along with lots of other good ideas) in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition - http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

Fred Brooks, author of No Silver Bullet[0] which GP is referring to, and the fairly famous Mythical Man Month[1].

[0] http://faculty.salisbury.edu/~xswang/Research/Papers/SERelat...

[1] http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

You might be interested in this book. It's required reading in many CS curricula:

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

Note: in the 20th anniversary 2nd edition of The Mythical Man Month (http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...), in one of the new chapters, Brook's backs off of his original "Build one to throw away" advice.

It's been a long time since I've read either, but I can state in general that software engineering concepts don't tend to get outdated. The state of the art stuff I learned in the late 1970's is still almost entirely valid, although when it comes to low level stuff you'd want to e.g. adopt the advice about goto statements to other non-local things we are confronted with nowadays.

So reading an old classic like The Mythical Man Month isn't going to be a waste of time at all and is strongly recommended, but later really good stuff like these two books have additional lessons we've learned since then. So read the 20th anniversary version of that book (http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...), in which the author revisits issues and e.g. modifies his advice to "plan to throw one (version) away, because you will". The potential state of the art has gotten better, you can often get away with not doing that.