Book club in our engineering team – Pragmatic Programmer
Tags: books, career, productivity, team
Published: 2019-07-03 15:14:43

---
title: Book club in our engineering team – Pragmatic Programmer
published: true
description: Book club in our engineering team – Pragmatic Programmer
tags: books, career, productivity, team
cover_image: https://thepracticaldev.s3.amazonaws.com/i/bqjp5ewf5j005oc81fif.png
---

_Originally published on [my blog](http://www.nikola-breznjak.com/blog/books/book-club-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:

- [1st - The Phoenix Project](http://www.nikola-breznjak.com/blog/books/implemented-book-club-idea-engineering-team/) (has way more info on how we're doing it)
- [2nd - It doesn't have to be crazy at work](http://www.nikola-breznjak.com/blog/books/book-club-engineering-team-doesnt-crazy-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](http://www.nikola-breznjak.com/blog/books/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](https://amzn.to/2ZsP8yu)

## 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**