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.
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.
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 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.
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?
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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 ..."
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.
"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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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."
- 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. 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
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.
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 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.
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.
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...
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.
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."
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.
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.
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.
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
"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.
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.
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.
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.
Most others here mentioned either business or computer science books, so this one sticks out to me. Is there a reason you say Final Exit, beyond a lame joke about wanting your colleagues to kill themselves?
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.