2. Independent Engineer Reading List
by Bobby Woolf, Gregor Hohpe
This book introduces messaging patterns and their proper use with goal to help you to design effective messaging solutions. Today this is especially interesting because we live in a period of the rise of microservice architectures. It explains possible components in services communication and the way we should think about those as well as the roles each component plays.
by Eric Evans
The subtitle itself (Tackling Complexity in the Heart of Software) gets to the point what this book is about. DDD tackles software complexity by focusing the team's attention on knowledge of the domain, picking apart the most tricky, intricate problems with models, and shaping the software around those models.
We have often heard engineers complain about it being too academic, even philosophic, without concrete instructions that can be used on real projects they work on. With that assumption in mind we recommend following two books that bring more practical approach, but following the ideas Evans has set up:
by Vaughn Vernon
by Nick Tune, Scott Millett
by Andy Hunt
My first introduction to this book was through 2nd chapter (Journey from Novice to Expert),which in detail describes how Dreyfus model can be applied in software development, and it was mind opening. This book will change your approach to thinking and learning and will teach you what can be done to improve those skills. If I will have to choose single book from this list to prove that reading is important part of improving your skills I would choose this one. After you read it you will want to read all others.
“Software development happens in your head. Not in an editor, IDE, or design tool.”
by Michael Kerrisk
If you are developing applications that are running on Linux, understanding how Linux works should be helpful. This book explains specifics of interaction between applications and the system itself. Regardless of how familiar you are with Linux, in this book you will find something new to learn.
by Merrill R. Chapman
This book chronicles the best of the worst business decisions over the last two decades in the technology industry, teaching us history lessons on how to avoid monumental mistakes. How is it possible that nine of the ten biggest high-tech software companies in the year 1984, crashed during the next 15 years and one prevailed taking over 70% of the market? That one didn’t make single crucial mistake.
“Micropro fiddled around rewriting the printer architecture instead of upgrading their flagship product, WordStar. Lotus wasted a year and a half shoehorning 123 to run on 640KB machines; by the time they were done Excel was shipping and 640KB machines were a dim memory. Digital Research wildly overcharged for CP/M-86 and lost a chance to be the de-facto standard for PC operating systems. VisiCorp sued themselves out of existence. Ashton-Tate never missed an opportunity to piss off dBase developers, poisoning the fragile ecology that is so vital to a platform vendor’s success. Netscape’s monumental decision to rewrite their browser instead of improving the old code base cost them several years of Internet time, during which their market share went from around 90% to about 4%.”
If there is one lesson to be learned from this book, it's the one that is found in the afterword where Joel Spolsky writes that the biggest mistake a company can make is to allow ground-up rewrite.
by Tim Lister, Tom DeMarco
Peopleware is the one book that everyone who runs a software team needs to read and reread once a year. In the quarter century since the first edition appeared, it has become more important, not less, to think about the social and human issues in software development. This is the only way we’re going to make more humane, productive workplaces. Buy it, read it, and keep a stock on hand in the office supply closet. (by Joel Spolsky)
Their premise is right: most software project problems are sociological, not technological. (by Frederick P. Brooks)
by George Spafford, Kevin Behr, Gene Kim
These two books (The Phoenix Project and Continuous Delivery) should be read in pair. First one, The Phoenix Project, is a novel whose influence on IT world can be compared with the influence Dr. Goldratt's book The Goal had on manufacturing. The other one is the Bible of DevOps practices. It shows us how, through automation of builds, deployment, and testing process, and improved collaboration between developers, testers and operations, we can deliver value to our customers more rapid and with higher degree of reliability. Together they form the basis for organizing modern DevOps workflows in software companies.
by Jez Humble, David Farley
by Andrew S. Tanenbaum, David J. Wetherall
Most Universities in their computer networks (and similar field) courses carry this book as a mandatory one and with a reason. Knowing the basics of Internet benefits everyone who is developing software that is used online. In several occasions we have used example of Two Army Problem from this book that phenomenally describes significant difference in application design when you are connected to network.