At the start of 2021, I read Peopleware. For a second time. Peopleware’s timeless, and iconic status comes from being able to provide a lot of quite simple answers for problems that, at first, appear technological but seem to be entirely sociological. As laid out in the book’s synopsis: “Peopleware asserts that most software development projects fail because of failures within the team running them.”
I finished the book and was fascinated by the changes in my perception about the advice given in the book, in particular when comparing to (what I remember) when I read it about 5 years ago. At the same time, I was struck by how much a lot of things haven’t changed at all. When I first read it, it was as if I had discovered a whole new world but, this time, not quite. It felt more familiar.
As a side note, 50 pages of Peopleware are about physical office spaces which is a bit ironic considering I have been working from home for the past year and so has a lot of the software industry - and we’re probably never going back entirely. These pages still apply, of course, to work-from-home setups, but these setups only make sense when it isn’t forced upon us but rather by our choice.
The authors of Peopleware laid it out clearly one of the main findings, explained as, and potentially one of the most important assertions in the whole book:
“The business we’re in is more sociological than technological, more dependent on workers’ abilities to communicate with each other than their abilities to communicate with machines.”
In my first encounters with the book, this perspective fascinated me. However, at this point, it almost starts to feel close to a truism. I don’t see this discussed much but it seems that, after about 5 years, if you are observing close enough, software engineering is, in fact, much more about sociology than technology. Of course, this will be highly impacted by where you work, the context in which you work and so on. There are a lot of variables to this. Nonetheless, it seems to still hold truthfully when starting to go over a typical day-to-day in your mind.
At an individual level, we are all humans, we are not robots. We cannot totally disregard emotion, ego, frustration, tiredness and socio-economic contexts in our day-to-day. A few examples of this can be having trouble communicating properly with a colleague, reacting in an unfair way to something minor because you are tired, performing a judgmental code review, or receiving a poor code review yourself that you consider unfair, and zoning out of a meeting in which you are supposed to provide invaluable insights. Furthermore, a lot of the software industry is based on personal tastes. Consider, for example, that coding styles are frequent sources of friction within teams due to different understandings of what “the best way” to do something is.
All of these issues are part of the day-to-day in the industry. These little issues can chip away all the happiness and productivity out of your soul. If you get enough of these, for a long time, you might actually end up giving up. Unfortunately, in most environments, these sociological issues are what most of us end up bringing home at the end of the day - it is not the technological issues that keep us awake at night. Even more unfortunate is that, a lot of the times, these issues aren’t discussed and are swept under the rug by managers.
At the team level, it is perfectly possible to have a collective of competent individuals that simply seem to be unable to work together - they can’t possibly form a team. This will, almost certainly, be due to sociological factors, rather than technological ones. As we can read in Peopleware, we don’t seem to known exactly what makes an incredible team but we know a few good reasons why teams aren’t great. Individuals in teams are competitive and that can hurt teams. Managers are fearful of performing poorly, and that can hurt teams. Organizations build bureaucratic processes to manage people, and that can hurt teams. Individuals share different core values and ambitions, and that can hurt teams. Teams are separated, working remotely for example, and that separation can be bad for a team to bond, and that can hurt teams. The way projects are managed can hurt each individual’s motivation and productivity, and that can hurt teams. These are just a few examples of mainly sociological issues that can hurt teams, none of them have any bit of technology in them.
Even hiring is deeply biased in our industry. You can have a truly competent individual that doesn’t make the cut due to sociological factors, and an incompetent one that gets hired because they socially more apt, even if they don’t know it. When we interview people, we are subconsciously biased. I know I try very hard not to be but you need to deliberately practice not to be biased while interviewing, it is very easy to subconsciously do it for a multitude of sociological reasons. A quick search turns up a few examples of how technical interviews are broken and some of these mention sociological factors.
Peopleware has been published in 1987 and the reason that it is still as relevant today as it was back then is exactly because of the premise of the book: software development projects fail because of inner failures within the teams that run those projects. We are humans, and we’ll keep having sociological issues, and we probably will keep failing. The least we can do is keep trying. When we realize and internalize that our problems will, for most of us, be more sociological than technological, we can then start to understand how we can make this better for individuals and teams, increasing overall happiness, motivation and productivity.
Latest comments (0)