Ask HN: What are the books you wish your colleagues had read?
There is a class at Georgia Tech I colloquially referred to as "making sure your coworkers don't hate you." It covered design patterns, software testing, and project management. I'd tack on a basic knowledge of databases to that. These are things you can gain a true functional knowledge of in a couple of weeks, and which not knowing might make senior engineers hate working with you.
So to mimic the class:
The Mythical Man Month
Design Patterns - Even if some of the particulars are not as relevant, it still provides a useful framework for thought.
Lessons Learned in Software Testing: A Context-Driven Approach
I'd also add Harry Potter & The Methods of Rationality. A lot of engineers can think empirically, but its not their first reaction. Going through this book helped make it second nature for me. Can't remember if a certain data structure is immutable? Now I'll write a couple of lines of code to see rather than go looking for documentation. A lot of big problems start as false assumptions. Having the instinct to think to test them and knowing how to will prevent a lot of wasted effort, regardless of your role.
How to Solve It by Polya also gets an honorable mention for similar reasons.
"How to Win Friends and Influence People" by Dale Carnegie.
I'm not saying my coworkers are a bunch of jerks, but it's got a lot of great advice for working alongside others and resolving differences.
---
"How to Not Write Bad" by Ben Yagoda.
I'm not saying my coworkers are all terrible writers, but for many of them, writing just isn't their thing. But learning how to avoid the most common writing problems is important for programmers, because everybody ends up writing some degree of documentation.
--
"Experimenting With Babies: 50 Amazing Science Projects You Can Perform on Your Kid."
I'm not saying my coworkers are a bunch of babies, but I wrote the book, so I want _everybody_, not just my colleagues, to read it.
"I gave my manager two copies of The Mythical Man-Month so he could read it twice as fast."
Actually my colleagues are pretty smart!
For most people, though, it's hard to beat Jurassic Park, the morality tale that goes something like "Myopic optimization leads to BEING EATEN BY DINOSAURS."
Storytelling with Data - because so many people are bad at PowerPoint: http://www.storytellingwithdata.com/book
R for Data Science - because it is such a solid foundation for a career in business analytics: http://r4ds.had.co.nz
And for extra credit two books I hope my collegues DON'T read since they are best kept secret are Cialdini's two books on influence: https://en.m.wikipedia.org/wiki/Robert_Cialdini
Working Effectively with legacy code (http://amzn.to/2CazEm5) and The Design of Everyday Things ( http://amzn.to/2H23a0R )
Both have a huge impact on how I work with code and design them. Trying to explain these concepts are hard without context. Sometimes i just copy/paste the sections i think they could benefit from.
Structure and Interpretation of Computer Programs (SICP) by Abelson, Sussman, and Sussman.
Full text is available here: https://mitpress.mit.edu/sicp/full-text/book/book.html (or PDF at https://github.com/sarabander/sicp-pdf).
It is IMHO the most important book on programming and programming languages ever published.
Snow Crash - Convincing possible future dominated by media, corporations, computers, and drugs.
The Origin of Consciousness and the Breakdown of the Bicameral Mind - Fascinating delve into, among other things, why Homer is boring but gets better, prehistoric art in early human cultures, schizophrenia, and perception and the points it breaks down.
(I work in VR games so take with a grain of salt)
Don’t Make Me Think: A Common Sense Approach to Web Usability.
The chapter about “religious debates” in particular was hilariously accurate, about how teams of people will argue about strongly held personal beliefs about things that can’t be proven.
Peopleware: Productive Projects and Teams
I mostly wish this to my ex and future managers, but colleagues wouldn't hurt as well.
Working in Berlin I'm constantly baffled how ignorant of the "old" research people are. Time and again.
Design patterns get obsolete. Programming languages get obsolete. Libraries get obsolete.
Mathematics doesn't. Learn CS foundations, logic, proofs to get better at understanding and gain abstraction experience.
Edit: books: How to prove it by D.Velleman, Proofs and concepts, Discrete Math by S.Epp
I am a proponent for depth over breadth. To read is one thing but to understand is another. Rather than read 5 books and superficially grasp their concepts, read one closely and carefully.
The one book I wish my colleagues would read and learn from is "Man's Search for Meaning" by Victor Frankl [1].
"Between stimulus and response lies a space. In that space lie our freedom and power to choose a response. In our response lies our growth and our happiness."
[1] https://www.amazon.com/Mans-Search-Meaning-Viktor-Frankl/dp/...
[0] https://www.amazon.com/Black-Swan-Improbable-Robustness-Frag...- Nassim N. Taleb: Black Swan and Antifragile[0] - Robert Cialdini: Influence: The Psychology of Persuasion[1] - Franklin Foer: World Without Mind: The Existential Threat of Big Tech[2] - Herbert Marcuse: One-Dimensional Man: Studies in the Ideology of Advanced Industrial Society[3][1] https://www.amazon.com/Influence-Psychology-Persuasion-Rober...
[2] https://www.amazon.com/World-Without-Mind-Existential-Threat...
[3] https://www.amazon.com/One-Dimensional-Man-Ideology-Industri...
All in no particular order....
As a Unix systems engineer, I would choose
As a Unix systems programmer I would choose1. W.R. Stevens books on Unix and Tcp/ip. 2. Rochkind's Advanced UNIX Programming. 3. Most of the Unix/Linux manual pages. 4. Bash FAQ1. Mythical Man Month 2. Jon Bentley's Programming Pearls. 3. K&R C and Stroustrup C++ 4. A recent Java reference and Bloch's Java Puzzlers 5. a reference and cookbook for the language of your choice -- Python, Ruby, Perl, etc. 6. Google's style guidesReinventing Organizations by Frederic Laloux - https://www.amazon.com/Reinventing-Organizations-Frederic-La...
For me it is the most influential book on how I think about "agile" , what that really means, and which factors really matter.
Principles by Ray Dalio
This is a good start for crafting better mental models and thought frameworks before engaging others in meetings.
Clean Code Series from Uncle Bob.
The books made me realize how horrible my codes are. No matter how long you've been programming, I think these books should be read by every single programmer out there.
Amusing Ourselves to Death - N. Postman
From the 80s, and talking of TV, but it's worth reading again today as it's so applicable to the current landscape. More so than its original target.
Just about anything. Too many coworkers don't read any technical books at all. Some will pick up books to learn specific tools or languages, which is better, but not enough...
If you made me pick one, though...
The Practice of Programming - Brian W. Kernighan, Rob Pike - http://www.amazon.com/Practice-Programming-Brian-W-Kernighan...
1984 just so they don’t get any crazy ideas and invent big brother. cough cough FACEBOOK cough cough
Fascinating question. I recently went about compiling a list of books that I though our team will benefit by reading (or re-reading). It was rather tricky to find books which are of lasting value and are best read in a contemplative frame of mind. Not necessarily intended to solve immediate problems, but to help become better in some immeasurable way. This is the list we collectively came up with. Our goal was to find 50 books and we went a bit above that in the end. YMMV. Link to list of books: https://docs.google.com/spreadsheets/d/1QOSqT2B_2skXlyG9lKI8...
"Everything is Obvious," by MSR researcher Duncan Watts.
Imagine every time when people infer seemingly-obvious extrapolations from data. This book addresses that phenomenon to make you more self-conscious about the limitations of data and the constant need for more research.
The entire "You Don't Know JavaScript" series of books by Kyle Simpson:
https://github.com/getify/You-Dont-Know-JS
Highly recommended because:
1/ They're up to date and you'll be able to avoid all the outdated JS tutorials on the web
2/ They're extremely well written
3/ They're thorough in a way that a lot of books and tutorials aren't. They are short, dense, incremental books and if you work through all of them you'll have a complete understanding of the language, including what's outside the so-called "Good Parts."
Effective Java by Joshua Bloch
Getting Things Done.
The engineers usually aren't so bad, because they have what's essentially a GTD system for 98% of their work in the form of an issue tracker (though I've also known one or two who could benefit from a system to help them track the complexity and non-code aspects of larger projects).
But the managers and the people I interface with in other departments are incapable of keeping track of what projects they have going on, what the next step are to keep those projects moving, and who's responsible for what.
Personally, though, I think there are book anti-patterns, too. If you start somewhere new or get new management and they hand out Machiavelli or Sun Tzu, You should probably update your resume and start taking recruiter calls; things are about to get rough.
I mean, those are important books, and you should read them for historical/cultural reasons, but if management hands them out at work, from experience, it's indicative of an, uh, unhealthy or at least unpleasant work culture.
The Mythical Man-Month - Fred Brooks
To all Project Managers & Top Management.
I would like it if my coworkers and managers read and took to heart the message behind
but sadly most are too focused on their stock options.• Six Degrees: Our Future on a Hotter Planet https://en.wikipedia.org/wiki/Six_Degrees:_Our_Future_on_a_Hotter_Planet • Drawdown: The most comprehensive plan ever proposed to reverse global warming http://www.drawdown.org/the-bookWorm, the amazing superhero deconstruction web serial, only so I could geek out with them.
Peopleware.
How about not stuffing people into open offices.
"Getting To Yes" https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit...
I've given away more copies of that book than any other. Improves all relationships.
"Elements of Style" aka Strunk and White. https://www.amazon.com/Elements-Style-Fourth-William-Strunk/...
I'd prefer they not only read Elements of Style, but work on it.
"The Soul of a New Machine", by Tracy Kidder. Solving hard problems, dealing with (and balancing) both technical and business concerns, but with emphasis on getting things done over process and organisational concerns.
1) The Pragmatic Programmer by Hunt and Thomas will always be a classic.
2) The Decision Maker by Dennis Bakke. This one pairs well with the more thorough Reinventing Organizations which has been mentioned in another comment.
Leaders and Self Deception
Crucial Conversation
These two books will teach you and your colleagues how to communicate and maintain an open and centered dialouge while removing bad intentions and bad mindsets from your being.
Nonviolent Communication
Dreaming in Code by Scott Rosenberg. As a programmer of 30 years I have taken more quotes and found more common ground with this book than any other. Here's a small extract that caught my attention: "In order to build something, you have to have a blueprint. And we don't always have one. Then you hit unexpected problems. It's hard to know how long something is going to take until you know for sure you can build it."
Anna Karenina and a selection of other classics. Anything from David Mitchell. At least a couple of the more well-known Haruki Murakami novels. Some history from the more scholarly end of the layman accessible works. Little bit of classic philosophy. More of my colleagues speak two (or more) languages than are monolingual, but if that weren't the case, I'd wish more of them read in another language.
Player piano by Kurt Vonnegut. Essential reading for anyone who forgets how powerful and often out of touch engineers are as a class of professionals.
The Denial of Death by Ernest Becker (http://a.co/aGEmQBl)
The Phoenix Project.
It's terrifying the parallels.
One of the worst managers I've had was actually well read. We read many of the same books and he also read many listed so far in this Ask HN. I often wondered how did he end up so bad if we read the same books?
Ross Anderson: Security Engineering - A Guide to Building Dependable Distributed Systems
Matt Bishop: Computer Security: Art and Science
Perl Medic is a phenomenal book about refactoring in the general case, through the lens of Perl
Chris Alexander’s Timeless way of building and Nature of order Robert Pirsig’s Lila
Crucial Conversations
You Are Not So Smart && The Halo Effect.
The lean startup and from zero to one.
1. Peopleware
2. Code Complete 2
Pragmatic programmer
undefined
McConnell, Steve. Code Complete. Redmond, WA: Microsoft Press, 1993.
McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.
Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.
Ranade and Nash. The Elements of C Programming Style. New York: McGraw-Hill, 1992.
Kernighan and Plauger. The Elements of Programming Style. New York: McGraw-Hill, 1982.
Caner, Cem, et al. Testing Computer Software, Second Edition. New York: Wiley Computer Publishing, 1999.
Hunt, Andrew, et al. The Pragmatic Programmer. Reading, MA: Addison-Wesley, 2000.
Holub, Allen. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming. New York: McGraw-Hill, 1995.
The bible
Any, really.
Final Exit.