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.
InitiatorFactoryFactory I do not mourne thee!
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...
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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 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.
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."
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.
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.
R for Data Science - because it is such a solid foundation for a career in business analytics:
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:
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.
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.
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.
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.
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)
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.
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.
I was considering the same thing. Outside of the reasons you listed you can also be viewed as smug / bitter.
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
The one book I wish my colleagues would read and learn from is "Man's Search for Meaning" by Victor Frankl .
"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
- Robert Cialdini: Influence: The Psychology of Persuasion
- Franklin Foer: World Without Mind: The Existential Threat of Big Tech
- Herbert Marcuse: One-Dimensional Man: Studies in the Ideology of Advanced Industrial Society
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
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
For me it is the most influential book on how I think about "agile" , what that really means, and which factors really matter.
This is a good start for crafting better mental models and thought frameworks before engaging others in meetings.
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.
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.
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".
Which works in theory, in practice it's not that that easy, especially since UB seems to cater for the most "religious" ones
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.
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.
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...
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.
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."
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 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.
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.
To all Project Managers & Top Management.
• Six Degrees: Our Future on a Hotter Planet
• Drawdown: The most comprehensive plan ever proposed to reverse global warming
How about not stuffing people into open offices.
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 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.
2) The Decision Maker by Dennis Bakke. This one pairs well with the more thorough Reinventing Organizations which has been mentioned in another comment.
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.
It's terrifying the parallels.
To me, the message was just how operations-focussed and, above all, anti-individualistic big chunks of our field have become.
Matt Bishop: Computer Security: Art and Science
2. Code Complete 2