Did you ever two nerds give a talk called "How Open Source Projects Survive Poisonous People (And You Can Too)"? Those nerds were Ben and Fitz. They took that toxic-people advice and put it together with a bunch of other advice and...
OK, is anyone still here? I guess you never saw that talk; maybe you work for a real software company and didn't think you could learn anything about surviving office politics from a couple of open-source loonie tunes? Nevertheless. This is seriously a good book. It talks about why you want to have some people skills to make your way through your life in software development. Even if you don't want to learn to play nice with others, it's good to at least learn to see what's going on around you so you can figure out when you've stumbled into a bad situation.
Some excerpts that you can use right away...
On initial design: "If you're trying to design something new, try to include no more than five people in your meeting—it's practically impossible to come up with new designs and make decisions with more than five."
On "distributed" offices: "If you're on a team that has remote workers, this means documenting and sharing decisions in writing, usually over email."
On chat: "Years before instant messaging became wildly popular, teams would hang out in an Internet Relay Chat channel and most of their discussions would be in a group chat." If your team isn't using IRC, you're missing out. (Yes, Wave was supposed to fix this. Too bad.)
On commenting code: "Comments should be focused on why the code is doing what it's doing, not on what the code is doing." ...especially Author: lines "...littering source files with your name is, in our opinion, more trouble than it's worth." That's what your source code control tool is supposed to keep track of, after all.
On code reviews: "Whether you review the code before committing it or after committing it, you should make sure every line of code that goes into your repository gets a second pair of yeyes on it to check for style, quality, and, of course, careless mistakes. Keep changes small and reviewable—changesets that are thousands of lines long are unreviewable for anything but formatting nits." This ican be news to students accustomed to write-and-forget code.
On managing, if you get tricked into it: "Above all, resist the urge to manage." Try to maintain a Bill Coughran-like light touch. Get your team eating lunch together regularly.
On code maintenance/cultivation/janitor work: "We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide."
