Aiming to continue my book reviews, after Violet was born I've managed in the past 12 weeks to finish 1 book. Some people read that much in a night. Anyways...
Peopleware, it's a book about software development, or so I thought. And while I thought it would talk a little bit more about technical aspects it was really a book the environment that is created for people who do software development and how to make that environment a good one.
It touches on some things that would border line on common sense, such as keeping the people working on a project together, trying to keep one person focused on one project, making sure that everyone has quite adequate space, realizing that building a team is hard and illusive, but once you have a solid team you really have something of significant value, and many other nuggets of wisdom.
If I can be so bold as to boil down this book (and its already pretty short) to an overarching concept, I would suggest that this book is about understanding the nature and triggers of software development and other knowledge worker jobs, and how they are likely different then other industries. And tackling this at a fairly low level. Like the chapters about furniture and space requirements. Things which are pretty easy to shrug off and imagine that they don't REALLY make any difference.
The book seems like it's aimed at fairly big institutions but I think there is still some application for smaller companies. While all the specific ideas don't scale the principles seem like they would apply at all levels.
They brought up one area that I had to disagree with, which is the standing meeting. At my work we have a short 15-20 minute meeting to talk about what happened the day previous and what is planned for today, standard scrum style meetings. In my estimation these are valuable and not as the book suggests a ceremony to ensure that I maintain my overlord position. I think they're useful because:
- they create positive pressure regarding what people are working on due to each person (myself included) making a public statement about their intentions,
- they allow an opportunity for helping each other if people are stuck,
- they create general awareness of what the rest of the team is working on, which can lead to serendipitous opportunities to work together,
- they help normalize the relationships by not letting anyone on the team avoid the other for more than a day and
- they create a small bit of regularity and structure in an otherwise fairly unstructured day
Anyways, that aside, for someone in a software company and particularly having some aspects of management it's worth reading.