Books

Book club in our engineering team – Pragmatic Programmer

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:

⚠️ 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 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

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
Written by Nikola Brežnjak