Originally published on my blog

TL;DR

In this short post I’ll tell you:

• how we implemented our third book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few quotes that we liked

You can read all about our other book clubs here:

• 1st - The Phoenix Project (has way more info on how we're doing it)
• 2nd - It doesn't have to be crazy at work

⚠️ If you're thinking that there's no time to read the books, check this post on the math behind reading 30 books per year. If you think that this book club thing is cool, and you'd want to be a part of the group that's 'allowed' to read 'on the job', shoot me an email 👍

THE BOOK

This time we read the Pragmatic Programmer

DATA POINTS

• avg(time to read) = 6 hours
• avg(liked the book) = 6.9 / 10
• avg(liked the book club) = 8.8 / 10

KEY TAKEAWAYS

• Quality is a team issue - the team as a whole should not tolerate broken windows
• Treat the documentation the same way you treat your code
• Prototypes are disposable and shouldn't go into production
• Crashing early makes life a lot easier when debugging code
• Decoupling is good, but as a group, we don't subscribe to the idea that your software needs to be so flexible that swapping out databases would just be as easy as changing a line of code
• Shell is way more powerful than GUI
• Don't be a slave to old code, always be ready to refactor
• Don't refactor and change functionality at the same time
• Take the time to spell out connectionPool instead of cp
• Treat code as gardening
• "Why" is more important than the "what" - don't blindly duplicate existing workflow when translating into code from manual processes
• Try not to be a slave to the methodology
• Overengineering is as bad as under-engineering
• Premature optimization is bad
• Making a project glossary to save time later on looking for acronym translations is a good idea
• The code should have comments, but too many comments can be just as bad as too few
• Attaching codenames to new projects/features is cool
• Tailoring your message to the audience is an important skill to have
• Don't tell your boss that it's done until it's tested
• Finding bugs early in the process saves money in the long run
• Learn a new language every year, and read a tech book every month and read non-tech books as well
• The word deadline comes from a line in prisons which if crossed by prisoners they'd get shot
• The book is mostly a refresher of techniques/ideas that we already know - new book coming out for 20th anniversary