the psychology of software teams

  • 3 min read

the psychology of software teams by cat hicks

Generally positive, some really useful ideas in here for me, with a few things to complain about. “Learning by copying” has really stuck in my mind — I think that was new information for me (that we generally learn via mimicry first and foremost, and that it’s challenging for folks to invent new tools and uses, but relatively straightforward to mimic and combine approaches that we’ve seen modeled) but it makes a ton of sense and lines up with my experience.

The anxiety stuff around code review was interesting, though I was left wanting more details around the intervention. I guess I could dig more into the bibliography there (the book is very well cited). The growth mindset stuff, focus on adaptability, and emphasis of bands not rockstars — this wasn’t new to me. I suppose, at a high-level, this book reinforces my priors, so I’m predisposed to like it (I went in believing already in the importance of adaptability/growth mindset and value of rock bands over rock stars). I was struck a couple of times by some roughness in the quality of the writing. Lots of obvious repetition, some clunky paragraphs that really clashed as I read them. To be fair to the book/author, I read this write after I finished the El Akkad book (which has, in my opinion, very strong prose) so almost any book would seem amateurish after that.

The book had to spend a ton of ink defending behavioral science generally — I was glad to see an acknowledgment of the reproducibility crisis in the field, and the myriad of problems in many famous/landmark behavioral science studies, but it’s tough to be incredibly confident in the broad assertions given the number of reversals the field as a whole seems to suffer from.

I’m also left wondering why software teams warrant a separate book. It’s not really unique, is it? Treating software teams as a profession that requires its own understanding of psychology reinforces one of (in my opinion) the most toxic ideas in software development, namely that the field is so unique and special that it requires unique and special approaches to wrangle. Why would software development teams have different psychological requirements than say a finance team, or an architecture firm? I think they likely share far more than they differ.

All told, an interesting and useful book — well researched, with accurate assessments and smart recommendations.