Ask HN: What are the books you wish your colleagues had read? | Hacker News Reader

Ask HN: What are the books you wish your colleagues had read?

225 pointsxstartup124 comments

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.

An addition directed particularly at cofounders: The Freelancer's Survival Guide by Kris Rusch. It is the single best book on entrepreneurship/running a small business I have ever read. It covers pretty much all the bases. It also covers an enormous number of the issues that you will inevitably encounter if you start a business, but likely have never experienced otherwise.

Design patterns feel completely obsolete now.

Not only does no-one at all talk about them, most of the design patterns themselves were harmful and are now completely unnecessary due to functional language features being available in modern languages.

Design patterns are like TDD, no-one wants to come out and admit it, but they were really, really bad outside of theory.

InitiatorFactoryFactory I do not mourne thee!

Could you please elaborate that? I still see patterns like Builders, Factories, Singletons and even sometimes a Strategy in Java. Why do you think they are bad? What are the functional alternatives?

Java's not a good example as Java 8 took so long to come along. Almost took them 10 years to catch up with the rest.

In modern C# you won't see hide nor hair of Factories, Singletons, etc.

Expect modern Java to be the same in a few years.

Well, what’s about the new HttpClientFactory... https://github.com/aspnet/HttpClientFactory

Yeah, what with the asp.net core team being such great devs, I'll definitely listen to them.

That team can't commit to anything and yet make regular sweeping changes to the framework depending on whatever the current flavour of the month is. This month it's DI, DI, DI.

They've been incredibly inconsistent since ScottGu left.

Singletons have fallen out of favor, not because of language improvements, but because of increased focus on unit testing, which does not work well with singletons. I believe this trend actually started earlier in Java than in .net.

They are not really bad. Reading about them can help you get familiar with how programmers usually name their patterns. But I don't think one needs to study "design patterns" to come up with code using builders, factories, and singletons. People should always know the optimal way to write their code (or almost optimal). They can come up with any design patterns when coding, instead of choosing some among the well-known ones.

In most cases, I think they are a solution waiting for a problem. Let the code grow organically at first and see later if a design pattern helps make it simpler, because we humans are terrible at predicting things, moreso the abstract ones.

But getting lost in a sea of abstraction is easy, it makes you a better architecture astronaut than the one that's sitting on a Tesla now on the orbit listening Bowie's music. Looks good, makes you feel an expert, but really it's almost as bad as selling snake oil.

We programmers, as a whole, should have a code of ethic conduct and a better moral ethos.

It is just the hype cycle...patterns were overhyped for a while some years back, so now it is hip to hate on them. In practice design patterns are just "recurring solutions to common problems" so whether they are good or bad depends the particular pattern and the context where it is used. "Recurring problems" can be all kind of things from limitations of a particular language or platform to universal software design problems, so it is hard to say anything in general.

Some particular patterns have fallen out of favor, like the "Singleton" which is problematic since it is hard to unit test. Instead dependency injection is preferred these days, although DI has its own issues. Some patterns have become so entrenched that some languages have added built-in support for them, which means, I guess, they are not really "patterns" anymore but "idioms".

Other patterns like say the "adapter" or "strategy" patterns are ubiquitous in OO and will be forever, whether you call it a pattern or not.

DPs were over-used by architecture astronauts. For a while I was encountering Factories nested several levels deep, and everybody was making Singleton objects for things that didn't need to be singletons. Ask ten people what a Visitor was and you'd get ten different answers, and there were a bunch of things named Visitor floating around that you needed to read the code of before using, because they were all traps.

I heard of shops that were forbidding code that couldn't be shoehorned into one of the patterns already enshrined within the Gang-of-Four book (even though the book says repeatedly that it is not an exhaustive collection of patterns).

So DPs are bad because, on average, they tend to be an indicator of bad engineering practices, such as cargo-culting and political games. They can be used for good, but if you are considering a position in a pattern-heavy shop it's probably worthwhile doing research into what their engineering org is like.

Are you implying that TDD is bad in practice?

The few times I've attempted to do test-driven development, I've ended up with code that passes the tests, but breaks in every possible way that is not specifically covered by a test.

Well, wouldn't it break in one more way if you don't have a test for it?

No.

The problem is that people all too often see the passing tests and think, "Great, I'm done!". They don't take the time to evaluate whether they have thought of all cases.

That doesn't mean they should not write tests for the cases they _can_ think about.

It's better to have some test cases, rather than no test cases. Even if only the golden path is tested, that's still better than nothing.

Obviously, tests are a good thing and they are an important part of QA. I'm not arguing against automated tests.

I'm merely trying to point out a weakness in the practice of "test driven development", where you write tests before you implement the functionality.

Since you already have tests while you work, it's really easy to just treat them as a checklist, and once all tests pass it feels like you are done.

But in reality, once the feature is done, that's when the hard QA work starts. You need to review the code, make sure you considered all error conditions, check if your assumptions hold throughout the execution of the program, ensure that your code is resilient to unexpected user input, etc.

TDD might be a valuable part of a development/QA workflow, but just introducing TDD on its own is not going to make your product any better.

When your product grows you normally shouldn't have time to evaluate all the cases. That's why you write unit-tests - so you wouldn't need to review all the cases when introducing new functionality. E.g. one of the product I was working on recently is made from several components. Couple components have 100+ unit-tests.

Design patterns are probably broader than just the classic collection of OOP patterns. If you use functional features, new patterns will arise (the most trivial and oldschool one maybe being map/reduce). The original definition wasn't even programming-related, so their scope is quite large.

I don't think being aware of design patterns is a bad idea. In the end, they are just recurring solutions for architectural issues that many developers independently invented to solve them. They just get a bad rep because people applied them even if it wasn't necessary.

If I remember correctly, the original GoF book was inspired by patterns in architecture [1], so it's more about naming patterns they have often seen, and not about "if you use these patterns, your code will be better". It's a glossary of sorts, so developers can use the same words for things. This aim is independent of language and paradigma; the authors just happened to see mostly OOP.

However, just like Asdfbla said: People started to use it as a kind of manual and applied the patterns no matter the problem. Again, the problem is more the people than the idea...

[1] https://en.wikipedia.org/wiki/Pattern_(architecture)

When I had to learn about design patterns at university I basically felt like they were trying to rename things to sound Architecture-ey that already had other names.

I always found myself interested in learning more about design patterns, thinking they'd help me solve problems smarter/faster. But it never seemed to work out – I usually just ended up preferring to write things several different ways and then evaluating the implications of each. And if they happened to be one of the "standard" design patterns, who even cares?

I really enjoyed this talk from Deconstruct 2017: "Patterns Failed. Why? Should We Care?" I recommend giving it a watch: https://www.deconstructconf.com/2017/brian-marick-patterns-f...

I really enjoyed that talk. Thanks for sharing. I usually cringe at design patterns, but hearing the intention behind the idea of design patterns resonated with me. Especially his final point about balancing abstraction.

How is the class actually called?

I believe it was CS 3300 - Intro to Software Engineering

Harry Potter & The Methods of Rationality - I'd to Google to see if that was really even a book.

Just a small pointer because I assume you're a non-native english speaker: you never (I think) contract an auxiliary verb before an unconjugated main verb. You have to write "I had to Google ..." The only reason I mention it is because it's an easy error to make but one that makes people have to read the sentence a few times to figure out what it means. If "to Google" was conjugated, you could write "I'd Googled that last week ..."

Thanks for this, Sophie!! I reiterated this from my GF who also happens to be a professor of English :)

As a native speaker, I've never thought in terms of auxiliary verbs, unconjugated etc, or known what they were. So I'm trying to think of the way native speakers learn, the natural rule.

Doesn't it depend on whether there's a stress/emphasis on the verb? I'd to seems wrong because the had in I had to is stressed, so the had just seems missing. In I'd love to - the would isn't stressed. If it is, like "I would love to, but I can't" then the contraction isn't used. It's how contractions arose in the first place, I guess.

I believe the experience of "stress" that you feel in this sentence is because "had" is being used as a modal verb. That is, it's being used to qualify the verb "to Google" rather than specify it's tense like in "I'd Googled that last week". Modal verbs are a type of auxiliary verb.

I don't know the "real" rule for when you can contract and when you can't, but I'm sure that there's some linguist somewhere who has written a paper on it. The reason that I didn't try to explain the stress that native speakers feel by talking about modal verbs is because I don't think that you can say in general that you never contract a modal verb. For example you can say "I would talk to Jim" or "I'd talk to Jim" where is "would" a modal verb modifying "talk". Maybe it's the case that the only time you have a phrase in the form of [auxiliary verb] [unconjugated verb] is when the auxiliary verb is being used as a modal verb? I don't know. I don't have any expertise in linguistics, I just know the terms because I took a class on it in college.

2340 (the mandatory group project course) also covered a lot of this stuff, though not in as much detail.

The suggested reading for that course is a book that blew my mind when I first saw it as an undergrad: Clean Code by Robert Cecil Martin. I believe the examples are all Java, but the lessons are applicable to any language. Stuff like naming your variables more carefully than you name your children.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

"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 loved experimenting with babies. Thank you!

Marian says hi! (I live with her.)

"I gave my manager two copies of The Mythical Man-Month so he could read it twice as fast."

Excellent!

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

"Just because you can doesn't mean you should" applies to so many situations in software development.

In terms of books to (gently) influence colleagues... I generally find myself looking for pretty-much the opposite. Something that emphasises the joy of stealing fire from heaven.

Old-school sci-fi (lots to choose from) could be pretty good in that regard. Newer stuff often leans a bit too much in the morality tale direction.

At the cost of being downvoted, I like The Fountainhead for this. Trusting your own judgement, daring to create something beautiful even if nobody else appreciates it, even if everyone else hates you for it. Because it's beautiful and because your singular vision improves the world by existing in it. And because you become a better person for daring to realize the great work that is inside of you.

The love story in it is kind of weird, okay really weird, but besides that I like the book. Most of the over-the-top strawman librul bad guys, and attempts to morally justify Laissez-faire capitalism mostly came from Atlas Shrugged. The Fountainhead is more focused on an individual who wants to realize greatness for its own sake.

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

Consider that powerpoint is not the right medium 95% of the time, but is being pushed as the only medium 100% of the time.

Why are they best kept secret?

Ostensibly to prevent them from using the techniques on yourself, or so that they don't recognize when you are using the techniques on them.

Aren't we talking about colleagues? Shouldn't it be a collaborative environment?

I meant it somewhat tounge-and-cheek, but if I recall correctly even Cialdini quotes Uncle Ben's line to Spiderman about "with great power comes great responsibility". I also should mention that I work for a large corporation, and while I strive to be collaborative, it is still a political environment I operate in.

His books weaponize common psychological traits and teach how to use them to achieve one’s means. An extremely toxic approach in my opinion.

I really enjoyed Sandi Metz’ talk on this very topic, in which she addresses the books and offers alternative approaches to creating influence through leadership and solid relationships.

It’s a talk I’d recommend for the whole team to watch, together.

https://m.youtube.com/watch?v=VzWLGMtXflg

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.

If anyone is interested in SICP, I strongly recommend finding videos of the lectures (which are free online) and watching those, then going back to the book for reference and exercises. I found the SICP book very hard work until I discovered the actual lectures that it is meant to support.

Here's a link for anyone else that wants it: https://www.youtube.com/playlist?list=PL8FE88AA54363BC46

OMG Thank you to both of you! I've seen dozens of references to SICP in lists online, but I never knew there's video of the course, no-one mentioned that. Great stuff.

After watching the first 10 minutes of the first lecture, was so good I immediately got my super-non-techy housemate to watch it, after explaining how revered among programmers the book is. She said "Thank you for showing me that!" hehe.

"After watching the first 10 minutes of the first lecture, was so good I immediately got my super-non-techy housemate to watch it, after explaining how revered among programmers the book is. She said "Thank you for showing me that!" hehe."

Yeah, the lecturers are really good, and IIRC, the videos were professionally produced (HP paid for them). The book is written like course material for a maths class, more than a commercial programming book.

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.

Seconded. At a couple of places I was actually thinking about leaving this book as a good-bye gift for managers when I quit. But that wiuld most likeky be effort and money wasted.

Hear hear.

I was considering the same thing. Outside of the reasons you listed you can also be viewed as smug / bitter.

Thank for this suggestion, I have just read the introduction and first chapter. This is my current company in a nut shell!

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

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

[0] https://www.amazon.com/Black-Swan-Improbable-Robustness-Frag...

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

Then your overall goal must be to persuade them of the black-swan collateral risks of the big tech sector in an advanced industrial society.

I'm in!

All in no particular order....

As a Unix systems engineer, I would choose

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

As a Unix systems programmer I would choose

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

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

I wish they hadn’t.

Clean Architecture is a plague on Android development undoubtedly unleashed by some obscure IDE programmer paid by the number of times you use the “Go To Definition” function.

CC seems to be Design Patterns meets Moral Harassment

It turns development teams into a judgemental arena, demeaning of other colleagues and a race to see who follows "the gospel" closer to the letter

Who says their code is clean? Who says that's the best way of doing things? In all cases?

It just reeks of "I'm better than the rest", which is already a problem in the industry.

While I agree that can devolve into a dogmatic belief system, I also think that that's partly a people problem.

Many of the ideas in Clean Code make code more readable (for example small methods, each containing only one level of abstraction; or good naming). It's on the coders to know how far to take these ideas and when to be pragmatic and say "good enough".

> It's on the coders to know how far to take these ideas and when to be pragmatic and say "good enough".

Which works in theory, in practice it's not that that easy, especially since UB seems to cater for the most "religious" ones

It isn't easy, but so far I've had luck with my co-workers. If they were more dogmatic, I think I would see Clean Code more critical too. But as it stands, I still recommend the book to new colleagues, and our culture takes care that we don't follow each "law" to its letter.

Yes isn't easy, that's why I'd rather avoid it

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

Mythical man-month was so good you put it twice?

"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

That book is awesome, should be read by every Java developer! Discussions and examples from this book is often on Stack Overflow too, where the discussions go deeper and may be clearer.

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.

Another good one for project management is The Checklist Manifesto by Atul Gawande. When running many large projects, there's always a common set of stuff that needs to get done before declaring a project ready for deployment. The techniques in this book are simple, effective and a lot more subtle than simply writing down a list.

I would like it if my coworkers and managers read and took to heart the message behind

   • 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-book

but sadly most are too focused on their stock options.

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

If you liked "Getting To Yes" you might also enjoy "Never Split the Difference: Negotiating As If Your Life Depended On It" https://www.amazon.com/gp/product/0062407805/ that has a somehow different perspective on negotiation

You might find this interesting regarding Elements of Style: https://www.washingtonpost.com/news/volokh-conspiracy/wp/201...

The original article it quotes can be found here: www.lel.ed.ac.uk/~gpullum/LandOfTheFree.pdf

It's quite heavy criticism of Elements of Style from the Professor of General Linguistics at the University of Edinburgh.

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

It's also extremely well written, and a great introduction to how computers work in the inside that can be understood by non technical readers. It's also the only book which succeeded in expressing both the rollercoaster I feel when programming.

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.

I was disappointed with Pragmatic Programmer, but maybe I picked it up too late. It is quite obvious stuff for experienced person. If someone is 5 years in dev and content of the book is not obvious for him, then I am afraid the book will not help.

I agree insofar as any developer should probably know that stuff as a minimal baseline. Which is why it made my list of books I wish my colleagues had read.

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.

Actual titles: Leadership and Self-Deception and Crucial Conversations.

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.

Just finished it. It is a good book. I expected it to be more from sw dev point. But I was not disappointed.

A lot of people have been recommending this book, including Patrick McKenzie (patio11.) I'm going to start reading it.

It's certainly an interesting read. But very oriented towards big, conservative organisations.

To me, the message was just how operations-focussed and, above all, anti-individualistic big chunks of our field have become.

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?

I don't think reading a lot of books is a panacea that will magically make you a better person, or even a better manager. It's important to have a lot of "mental models" to make better decisions, but books won't fix a short temper or make someone more friendly. That comes from habits like reflection and meditation, or therapy. Also getting enough exercise, having a healthy diet, getting enough sleep, not working too much, and not having too much stress.

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

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.

Reply on news.ycombinator.com