Engineering Book Club

An online community to read and discuss engineering books with other professionals.

Account managed by @miguelbemartin

[Engineering Book Club @TheEngBookClub]

We are in Discord now! https://t.co/zOlaPa2uOR

[Engineering Book Club @TheEngBookClub]

Reading is not enough. The real learning happens when you write notes, apply what you read, and discuss it with others. Here is how to make engineering books stick.

https://t.co/WY6hAkzvgy

[Engineering Book Club @TheEngBookClub]

You do not need to read every word from cover to cover. With the right strategy, you can get through most technical books in about a week and retain what matters.

https://t.co/pQfufszR4E

[Engineering Book Club @TheEngBookClub]

New section on our website: Currently reading and what's coming next.
https://t.co/AjLADccwRB

[Engineering Book Club @TheEngBookClub]

Blog posts and videos are great for getting started. But when you want depth, structure, and ideas that stick, nothing beats a well-written engineering book.

https://t.co/5TzPi18Z7I

[Engineering Book Club @TheEngBookClub]

Over the years, a handful of books completely changed how I think about writing software. Here are the five that had the biggest impact on my day-to-day work.

https://t.co/fjNsvNHsoU

[Engineering Book Club @TheEngBookClub]

Tutorials teach you how. Books teach you why. If you want to escape tutorial hell and build real understanding, start reading engineering books.

https://t.co/HTh5FfTdHX

[Engineering Book Club @TheEngBookClub]

In "Coders at Work," Seibel interviews 15 famous programmers. Common thread: They all read code constantly. Reading others' code teaches you patterns, anti-patterns, and different thinking styles. You can't learn to write well without reading widely.

[Engineering Book Club @TheEngBookClub]

"Building Microservices" explains that the hardest part isn't the code, it's the data. When you split services, you split databases. Now you have eventual consistency, distributed transactions, and data synchronization problems. Microservices create data problems.

[Engineering Book Club @TheEngBookClub]

"Domain Driven Design Distilled" is Vaughn Vernon's shorter introduction to DDD. It covers bounded contexts, aggregates, and domain events in 150 pages instead of 500. Sometimes you need the condensed version first to know if you want the deep dive.

[Engineering Book Club @TheEngBookClub]

"Agile Estimating and Planning" by Mike Cohn teaches that estimates are about conversations, not precision. Story points work because they force discussion about complexity and unknowns. The conversation is more valuable than the number.

[Engineering Book Club @TheEngBookClub]

In "Implementing Lean Software Development," the Poppendiecks adapt Toyota's manufacturing principles to software. Key insight: Inventory in software is partially done work. Every feature branch, undeployed code, or unvalidated assumption is inventory that costs you.

[Engineering Book Club @TheEngBookClub]

"The Mythical Man-Month" explains that perfect software is impossible because specifications themselves change during development. You're not building to a fixed spec, you're learning what to build while building it. Accept this reality, plan for it.

[Engineering Book Club @TheEngBookClub]

https://t.co/9fpQlxvDuc

[Engineering Book Club @TheEngBookClub]

Currently reading: Tidy First by Kent Beck.

[Engineering Book Club @TheEngBookClub]

"Clean Craftsmanship" by Robert Martin argues that professionalism in software means discipline. Write tests first. Refactor constantly. Communicate clearly. These aren't optional nice-to-haves, they're minimum standards for professional work.

[Engineering Book Club @TheEngBookClub]

"Software Architecture: The Hard Parts" addresses the hardest question: When should you break apart a system? The book provides decision frameworks for granularity, data ownership, and workflow management. Split too early or too late, both hurt.

[Engineering Book Club @TheEngBookClub]

In "The Art of Capacity Planning," Allspaw teaches that capacity planning isn't about servers, it's about headroom. You need buffer between normal load and system limits. Running at 90% utilization means small traffic spikes cause outages.

[Engineering Book Club @TheEngBookClub]

"Patterns of Enterprise Application Architecture" by Martin Fowler catalogs patterns like Repository, Unit of Work, and Service Layer. These patterns aren't trendy, but they solve real problems in business applications. Understanding them prevents reinventing wheels poorly.

[Engineering Book Club @TheEngBookClub]

"Implementing Service Level Objectives" teaches that 100% uptime is impossible and expensive. Choose meaningful SLOs (like 99.9%) and use error budgets to balance reliability with feature velocity. Perfect is the enemy of shipped.