Interesting UX thoughts on number inputs vs brackets for various types of questions common in surveys.

Good advice about provider-specific sporadic DKIM failures (Microsoft in this case). As the post says, this is a problem that’s been around for a long time, and yet people never seem to believe it could be the case.

Interesting corollary to Chesterton’s Fence.

This command history logging is so much better than making HISTSIZE huge, which is what I’ve always done. via

“80% of your time goes to low-risk/reasonable-reward work, 15% of your time goes to related high-risk/high-reward work, 5% of your time goes to satisfying your own curiosity with no thought of reward”

Python monolith organisation, particularly interesting:

• Using import linter to enforce layered imports.
• Charting tech debt progress over time.

“Prefer to push fixes upstream instead of working around problems downstream”

“Waste, inefficiency, a suboptimal outcome. Some of the brightest minds in our economy are earnestly engaged in stamping it out. They’re winning, but everyone’s losing."

Using ‘process linters’ to avoid hitting ‘feedback budgets’ (the appendices are the most interesting part).

Interesting post-mortem on a bug caused by changing randrange() behaviour across Python versions.

“People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it.” Jacob Kaplan-Moss - I have done & seen this too. Worth it, when you pick the right job.

Interesting introduction to ChatGPT’s Code Interpreter via Simon Willison

I’ve used all of these deployment patterns (really release patterns), and strongly prefer feature flagging everything with a layer of permission for user-facing changes as well.

“Where are the networks that deeply in their bones understand hospitality vs. performance, safe-to vs. safe-from, double-edged visibility, thresholds vs. hearths, gifts vs. barter, bystanders vs. safety-builders, even something as foundational as power differentials? I don’t think we have them, except piecemeal and by chance, or through the grace of socially gifted moderators and community leads who patch bad product design with their own EQ."

Good post on why speed matters although it completely misses any discussion of quality, which is critical. It’s all about balance, not just prioritising for speed.

Summary of a paper covering the past, present, and potential future of tech debt.

Interesting thoughts on monitoring (logs, metrics, traces).

Good intro to using Vulture with Django.

Deep dive into tech debt and the financial debt analogy (good for people not that familiar with finance, or, probably, people familiar with finance but not tech).

Speaking of Ben Hoyt, another post with more details on good naming.

My thoughts on Pythonic library API design in response to Ben Hoyt’s post a few weeks back. More on the stdlib email package when I find time.

Good list of lessons learnt in software engineering.

“1966! … Yet this person seemingly knew more about software development in 1966 than most managers of software product development companies do today. These are not new ideas, and sometimes it baffles me that they are not more widely known”. So true, and so sad.

My first experiments with using an LLM to help write code - TL;DR: disappointed so far.

Stamina looks great - an opinionated wrapper over Tenacity [via Simon Willison, who is for some reason still linking to Tweets?]