Three books changed my life as a programmer. [Kernighan1981] taught me I could do more than just write software: I could design it. [Glass2002] taught me we could investigate software and software development scientifically to determine what actually works and what doesn't.
In between those two books I read [Hunt1999]. For many programmers of my generation, it was the first time someone had described the craft of software construction in a way that made sense. I referred to it over and over again when I started supervising undergraduate projects at the University of Toronto in the early 2000s.
Looking at it now, though, I am struck by what it doesn't discuss. How do you run a meeting in a way that ensures everyone is heard? After forty years in tech, I believe that is the most important skill I ever learned. Why and how do tech companies build products that people don't want? Why do they marginalize women, people of color, and members of the LGBT community when all the evidence shows that more diverse teams are more productive? And given how online platforms have fueled radicalization and disinformation in ways that threaten us all, shouldn't every guide to being a better programmer at least mention the problem?
One book can't answer all those questions, but now that we all know how much harm software can do, I hope you'll be interested in some practical idealism.