what i'm reading: May 24

Finally caught up with my reading list backlog, which is good because I subscribed to three new mailing lists last week and maybe now I’ll have time to read them.

Engineering effectiveness

Tutti Quintella writes a lot of good content about creating effective engineering cultures; my favourite so far is her presentation on scaling software development
I felt like I’d already read some post about the math supporting the usefulness of a platform team, but this one by David Jared of Adobe was apparently not it and had some fun, comprehensible graphs.
The previous platform post led me to the source of the graphs, Peter Seibel’s funny post about Twitter growing pains intriguingly titled Let 1000 flowers bloom. Then rip 999 of them out by the root. This one is square in my wheelhouse of dev experience, and I’d like to hear about how effective the Engineering Effectiveness team has been over the past 5 years.
Francisco Trindade has a post about what metrics he uses for engineering management and why, a topic I have also been spending a lot of time on lately. I agree what matters is trend lines, not specific numbers, though some of the particular metrics he uses assumes a homogeneity among how different teams use kanban software, which I’m not sure I can depend on.
Pat Kua’s older post on appropriate use of metrics dives more into the pitfalls of using the wrong metrics or trying to use them the wrong way.

Case studies

This Netlify case study of how they increased deploy speeds solidified in my mind the need for diagrams when trying to explain architecture changes. I still wouldn’t say I understand what Netlify does, but thanks to the sequence diagrams I at least grasp the shape of what their refactor did and why it improved performance.
Stephanie Morillo’s Bundler.io case study provides interesting examples of how to identify the effectiveness of documentation.

UNIX tools

Avdi Grimm makes a great analogy about small, sharp tools and when the UNIX command-line philosophy is maybe not the best solution.
Tim Bray wrote about a little side project to replace a common Unix pipeline task with a Go program that left him with an interesting puzzle about how little tools like this perform. The comments are full of interesting commentary and links.

Software architecture

Shubheksha Jalan explains retry storms and how to prevent them, with comics as illustrations.
Scott Wlaschin’s primer on functional architectures for Increment is intriguing, but still contains too much jargon I only vaguely understand for me to feel confident in the concepts. I’m starting to understand how some of these patterns/frameworks/languages are related though. I’d like to see more concrete examples of how people implement real software in a functional architecture, and what compromises have to be made.
Was excited to read Heidi Howard’s new paper on consensus, Paxos vs Raft! Conclusion by Howard and co-author Richard Mortier seems to be that Paxos isn’t so much a more complicated algorithm than Raft, as just less-well described.

Leveling up your engineering skills

Denise Yu’s recent epic on ramping up on large software projects at GitHub is chock-full of useful advice and anecdotes. I have no idea how she managed to put out four long, high-quality posts in four days this weekend, but I also recommend How to Talk about Software at Scale and Habits of High-Functioning Teams.
Felienne Hermans points out the lack of formal instruction on how to read code, and how she applied the concepts of “close reading” to propose “code reading clubs”. I admit I am fascinated, and the recommended exercises remind me Chelsea Troy’s Leveling Up skill of commit tracing. Definitely want to incorporate this into my life.
Monica Lent has a free newsletter on blogging for devs that contains a ton of useful advice if you want people to see and enjoy your blog! Unfortunately last week I didn’t have the time to follow along with the homework so I am here putting out a link post again instead of any substantial content. 😅

People management

Chelsea Troy re-linked to her post railing against “smart” as a hiring criterion, and while I—a self-identified “fast learner”—would like to quibble, she has a good point that innate brilliance does not necessarily correlate to “producer of maintainable code” or “good mentor to other engineers”.
Apparently half my Twitter feed is talking about feedback because a lot of companies are doing performance review around now, which gave better context for why someone linked to Jo Crossick’s opinion about why feedback is bad, actually. The part I most agree with is that the more senior you get, the less able you are to give casual feedback, because people will take it as fact regardless of how lightly you mean it.