This article on “non-blocking code review” keeps knocking around my head. As part of wanting to move closer to that, I've written a small tool to view commits related to a ticket. I want to grow this into a full code review tool; haven’t yet decided whether this will be written in Ruby or be used as an opportunity to play in a new language.
Watched Making Hard Things Easy, Julia Evans’ talk at this year’s (final 😢) Strange Loop. I always find her attitude and outlook inspiring and refreshing.
Just started Accelerate. From Courtney Kissler's forward:
work is work (don't have a backlog of features and a backlog of technical debt and a backlog of operational work; instead have a single backlog because NFRs are features and reducing technical debt improves stability of the product).
Mulling over the idea that a good way to track the stability of an application (in terms of the amount of bugs introduced over time) is to track the number of support tickets raised per-project. This would probably benefit from a severity rating and classification, also.
I thought this was particularly insightful: (from Dr. Greg Wilson on the Embedded podcast):
Code is a user interface and everything we know about HCI can be applied to it.
Different people have different standards for the speed of unit tests and of their test suites. David Heinemeier Hansson is happy with a compile suite that takes a few seconds and a commit suite that takes a few minutes. Gary Bernhardt finds that unbearably slow, insisting on a compile suite of around 300ms and Dan Bodart doesn't want his commit suite to be more than ten seconds