I would counter balance that book with one on listening, the other half (and much neglected part) of communication. Unfortunately I can’t think of any off the top of my head. Susan Cain put out a excellent book called “Quite”. It’s not quite on point for this topic but it may be worth a read.
Let me second that, since I don't have mod points right now. Communication isn't real communication if you only ask others when you have a problem or they are your boss telling you what needs to be done. The internships I did while in Uni, I had two that were of the later form, where I'd talk to a professor, then go write the code they wanted and turned it over and moved on to what ever else they needed. No collaboration, no meaningful communication. Those projects, from my coding perspective, turned to crap and I felt like I did very little in the scheme of things. On a different project, the Ph.D I was working for wouldn't accept that; she didn't know enough about code to just hand it all over to me to do as I wished, but she also wanted to understand what I was doing in software and get my feedback on the human interface side of the project (HCI isn't my specialty at all). 90% of my brainstorming and notes and test code were done at home (still billed, of course), but I was generally only allowed to write the final code when we were both in a lab working on the project. Traded notes on the artwork, debated the file formats that would work, maximum polygon counts, and so on. We also BSed about music, books, movies, whatever. It didn't cut into the workflow, because we both understood that once a brainstorm hit you either worked it out or forgot about it; but between intense bursts of coding we just chatted while we brainstormed. End of the day, we'd trade notes and comment some more on anything that jumped out. Beat a lot of roadblocks that way, like finding the polygon limit, acceptable file formats for models in the engine I was using ("what do you mean, I have to export? Can't the engine just us a Maya file? Can't you make it use the Maya file?") instead of banging up against those walls much later and having to do some last minute kludge to jam an incompatible file type into a graphics engine. If we had waited, I would have just gotten finished files in an email, and had no way to install Maya and convert the files to something usable, and would have been forced to learn a file format and code a parser for it. Instead, she just told Maya to use a format we could agree on. Days of work that would have been past deadline, averted.
The other projects, no one asked for my notes on. I was halfway done implementing a user editable AI, where each creature would load it's own script from a master AI class that just handled object creation and destruction. Since I kept getting sidetracked to other parts of that project, by the time my days there were up, there was only a skeleton of this AI with some notes on how each part connected. The next intern or grad student probably scrapped it and started over. The tools didn't have a good place for my notes, and even when I offered copies of the notes and diagrams they weren't taken; so no loss to me.
And that's why just sitting and BSing about music or books or movies or whatever while working can result in better code. You have to listen when a colleague brings up a minor concern, or just a stray thought, and see if that applies to something that you are working on. And if it is, then you can take some time to work out what looks like a small detail ("No, I don't think you could create a model that was too high poly count. Maya should limit you....wait, you are using over a million for just the eye? wt...") that may be a bigger problem than anyone thinks. But if you skip the small talk and don't listen to the minor concerns that aren't really your area of expertise, you may miss the clue to the issues that you'll be forced into dealing with later.