Thanks for writing and sharing this. It's not something I dived into deeply so feel free to ignore my opinion. But the main thing I feel this book lacks is a "show don't tell" mentality. I haven't read the content close enough to judge how insightful the technical nuts and bolts are. But one thing I learned only after working in software dev is the human aspect behind the pace and rhythm and success of projects. It's not just code and processes, but why such processes were implemented a n the first place.

I'm violating my own principle, so I'll give an example: the book, Enterprise Rails, opens with a chapter titled, " The Tale of Twitter". Here's an excerpt:

https://dan.chak.org/enterprise-rails/preface/

> Because Twitter was the largest, most public Rails site around, its stumbles were watched carefully, and the steps Twitter took to alleviate its scalability issues were thoroughly documented online. In one instance, the database was becoming a bottleneck. In response, Twitter added a 16 GB caching layer using Memcache to allow them to scale horizontally. Still, many queries involving complex joins were too slow. In response, the Twitter team started storing denormalized versions of the data for faster access. In a another instance, Twitter found its use of DRb, a mechanism for remote method invocation (RMI), had created a fragile single point of failure. It replaced DRb with Starling, a distributed messaging queue that gave it looser coupling of message producers and consumers, and better fault tolerance.

> It is of no small significance that Twitter’s engineers chose to absolve Rails of being at fault for their problems; instead of offloading the blame to an external factor, they chose to take responsibility for their own design decisions. In fact, this was a wise choice. Twitter’s engineers knew that reimplementing the same architecture in a different language would have led to the same result of site outages and site sluggishness. But online rumor mills were abuzz with hints that Twitter was planning to dump Ruby and Rails as a platform. Twitter’s cofounder, Evan Williams, posted a tweet (shown in Figure 1 ) to assure everyone that Twitter had “no plans to abandon RoR.”

It's not that every chapter should open up with a jaunty Malcolm Gladwell-seque tale about the life of loves of professional development. But some of your assertions could be made more compelled with some real-world examples:

> As a student of computer science and programming, you’ve learned a significant portion of what you need to know as a rookie professional. The most difficult parts perhaps, but far from the “whole enchilada.”

There's nothing wrong with that statement. But there's not much to it besides filler that students have been told for their entire college education. You yourself must have a few personal examples of what the first week of work taught you that 4 years of college didn't. And/or, you may remember a few interns who, despite their college pedigree, found themselves to be completely over their heads. Just even a couple of sentences of showing how you came to learn the wisdom you now dispense goes a long way.

Anyway, sorry for the extended critique. I am obviously skipping over the part above to how damn hard it can be to find compelling stories :)