Pragmatic Book Club: Chapter 3
I thought this was a pretty unchallenging chapter. Thanks in part to the success of this book, the sections (on the importance of plain text, the shell, fluency in the text editor, version control, debugging, text manipulation and engineering day books) went down very easily because these behaviours are all so deeply part of our working practices.
One theme that came up in our discussions a lot was how all of these techniques are very personal to the individual. This meant there was a lot of scope for discussions around favourite productivity hacks but nothing where we all agreed something was “essential” to being a great software engineer.
On with the questions
I didn’t come up with questions for every section as some of it was so uncontroversial I didn’t think there was anything interesting to discuss.
Editor fluency
How many of these can you do?
- When editing text, move and make selections by character, word, line, paragraph
- When editing code, move by various syntactic units (matching delimiters, functions, modules…)
- Reindent code following changes
- Comment and uncomment using a single command
- Undo and redo changes
- Split the editor window into multiple panels and move between them
- Navigate to a particular line number
- Sort selected lines
- Search for both strings and regular expressions
- Temporarily create multiple cursors based on a selection or a pattern match and edit the text in parallel
- Display compilation errors in the current project
- Run the current project’s tests
How are we at these? Anybody really good (I am bad -sadblob) ? I feel like there must be an online game somewhere where you can test yourself on these types of skills.
Does anyone fancy “losing their mouse/trackpad for a week and going keyboard only”?
Shell games
Who is a shell wizard? Share your favourite shell commands and combos in the comments.
Debugging!
Another thing I think we can all pat ourselves on the back about is how blame-free our engineering culture is at the FT. I reckon that starts with our approach to dealing with big outages, where there is a “blameless post mortem”, and idea I first heard about from Etsy.
Text manipulation
using [languages like ruby, python] you can quickly hack up utilities and prototype ideas — jobs that may take five or ten times as long in conventional languages
What features of a language make it “conventional” in the author’s definition do we think?
Further watching: Tom Stuart gave a good talk in 2011 about Ruby which contains a nice framing of what language features are important to him and why he loves Ruby so much. I always share this with people who are puzzling out the differences between languages.
Like a lot of this chapter, the section on engineering daybooks was interesting and led to interesting discussions about what works for individuals
Engineering day books
Humble brag: I have had kept an engineering day book for the last seven or so years.
Increasingly weird brag: I use a slightly more chill variation on bullet journaling to keep things somewhat organised. I use the Leuchtturm1917 A5 with dotted pages and I only write in it in BLOCK CAPITALS using a uniball eye fine in black because I have found that ink never smudges.
This practise is incredibly valuable to me as it builds in a monthly reflection on all the things I have to do, and it means I always have a list of to-dos to turn to when I sit down.
I noticed Arjun mentioned using Obsidian recently, anybody tried it?
What do you do for managing to-do lists, what’s good/bad about your approach?
