Pragmatic Book Club: Chapter 1
The point of these blog posts is that you, a stranger on the internet, can also run a book club with your pals. So while it’s tempting to put a lot of book review type content in here, I’m going to keep that brief and then share all the “provocations” I took to the group on this chapter.
General observations on “A Pragmatic Philosophy”
Firstly, what came across from all discussion groups was something along the lines of “this is a very US masculine coded book and we are trying to ignore that as there are also some interesting ideas here”. In part, the problem is particularly pronounced in this chapter because it is all about personal responsibility rather than software concepts, so the authors personal experiences come through very clearly and, unfortunately, failed to resonate with a lot of the book club.
For example, references to Navy Seals, or a story about some soldiers boiling some stones(??), a reference to broken windows policing, but no mention of how (a) racist and (b) debunked that policy is by this year, 2022.
Some things to discuss with your group
I gave every break out group these questions to discuss or ignore as they wanted, and then at the end we regrouped and shared discussion highlights.
- To what extent do we agree with the following:
Programming is about trying to make the future less painful. It’s about making things easier for our teammates. It’s about getting things wrong and being able to bounce back. It’s about forming good habits. It’s about understanding your toolset.
The process of becoming a good programmer doesn’t just happen because you know how to code, it must be met with intention and deliberate practice.
2. “Hopelessness can be contagious” where have we seen contagious hopelessness? Do we have any at the FT?
3. This chapter also talks about the “broken windows theory” which has come from a 1980s policing policy in the US. That theory has since been tested, and it’s limitations considered. What limitations and risks do you think there are when applied to code?
4. A challenge verbatim from the book:
Help strengthen your team by surveying your project neighbourhood. Choose two or three broken windows and discuss with your colleagues what the problems are and what could be done to fix them.
Can you tell when a window first gets broken? what is your reaction? If it was the result of someone else’s decision or a management edict, what can you do about it?
5. On “good enough software”, where at the FT do we have different values for “good enough”?
6. On investing in your knowledge portfolio who does any of these? Are they sensible?
learn at least one new language every year
read a technical book a month
read a non-technical book too
take classes
participate in local groups
experiment with different environments
stay current
