August Book Review
Development books I've been reading in the month of August.

This post will be slightly informal as I’d like to take some time to go over what I’ve been reading for the past month.

In no particular order:

The Mythical Man-Month

This one’s all about how we as engineers tend to underestimate how long a software project will take to complete. The “man-month” is the amount of work that one man (person, nowadays) can complete in a given month. It represents the ideal, however it is rarely realized, leading to estimate overruns. When a project falls short of completion by a certain date, additional team members are often added to the project to fill the gap – counterintuitively adding even more of a delay. Brooks postulates this is a result of even more communication requirements between team members as they need to be brought up to speed before they can work effectively.

This book was originally written in 1975 by the manager of the OS/360 project, and as such, a lot of the examples are badly out of date. Nevertheless, it is a classic. You’ll get to see the original usage of the phrase “the bearing of a child takes nine months no matter how many women are assigned”, which I’ve used myself when giving estimates to superiors. If you pick this one up, go for the latest anniversary edition with four additional chapters that may be more relevant to today’s work.

Adopting Elixir

Written by a trio of engineers whose expertise includes writing efficient and scalable applications in Elixir to the author of the language itself, this book is not so much a roadmap to implementing ideas in Elixir as it is an encouragement to adopt the language for yourself. That may or may not be an issue for you depending on what you hope to get out of the book. If you’re looking for tutorials to get an application up and running, Adopting Elixir is not for you.

On the other hand, if you want to know Elixir’s roots in Erlang, what the OTP is, or the origins of BEAM, as well as some promising features that a functional language like Elixir can offer, you should pick this one up.

Pragmatic Programmer

I think this best way to write about this book is actually to write the very first line of the first chapter.

This book is about you.

Specifically, this book is about you as a developer. As developers, we (hopefully) strive to be the very best at our craft as we can be. I can assure you that this book is the textbook for you if you’re looking to accomplish that goal.

Dave Thomas and Andrew Hunt tackle everything from the abstract such as developer mindsets and design philosophy to the concrete, such as testing best practices and code organization. I mentioned before that this is a textbook – this is absolutely true. Although I read it through cover to cover on my first pass, moving forward I plan to use it more as a reference whenever I have questions.

Of all the books in this list, this is the most important as a must-have. If you’re looking to buy, much like The Mythical Man-Month, go for the anniversary edition as some of the earlier books are quite dated at this point.

Clean Architecture

This is the only entry from Uncle Bob on this list. I’ve also read his Clean Coder (not to be confused with Clean Code) and I can recommend that as well, although I read it years ago whn I was just breaking into the software development industry. If ou liked the design philosophy sections of the other books, you will enjoy Clean Architecture as it is much of the same, but in expanded detail and with more up-to-date examples. This book is a must-read for upper level engineers and architects, if nothing else to get your own opinion of what not to do.

I must point out that there are lots of sections I disagree with, such as parts dealing with architecture of frameworks – especially opinionated frameworks like Ruby on Rails. I feel that those opinions are formed by countless others and going against them is hazardous in a majority of use cases. Similarly, a cased is made to abstract away details of database implementation on your own, which is fine in cases of frameworks, but I have yet to see a database swapped out in an application without countless hours of effort and very good reasons.

Cracking the Coding Interview (6th Edition)

This one’s been sitting on my desk for a while, so technically it’s cheating since I just reference it every now and again. In fact, if you’ve been following along with some of my other posts you will know that I recently went through the interview process again and have been reading this one lately.

It is the guide to technical interviews. It’s definitely a textbook, clocking in at almost 700 pages, but it covers everything you would like to know about interviewing for high-level tech companies. And not just technical interview questions – this covers everything from the format of technical interviews, CS fundamentals to freshen up on, navigating offer negotiation, to how to handle your first days on the job. I’m particularly interested in these sections now that I’ve accepted a job offer.

Buy this book for the data structures and algorithms, and utilize it often for continued success in your career.

That’s all for now. Thanks for reading!