Fun debugging story - I got hit with this getpass limitation too, although in a less (potentially) catastrophic way.

Suggestions on how to build software. ✅= matches my experience, ❌ = not wrong, but not my experience:

✅ Developers are most effective when they’re familiar with many systems, not just one or two. ❌ Automation (e.g. continuous deployment) can cause as many problems at it solves. ✅ Keep the dev cycle near-instantaneous. ✅ Take advantage of the recency bias. ✅ Prefer projects with small organizational scopes. ✅ Check in often, with everybody, about a project’s perceived value. ✅ Don’t measure proxies. ✅ Allowing developer autonomy will make or break a project. ❓ Metrics are for software, not people. ✅ Everybody wins when people can just manage themselves. ✅ Intrinsics play only a small role in human potential. Metrics are for software, not people. Everybody wins when people can just manage themselves. Intrinsics play only a small role in human potential.

Interesting advice on picking tools.

Nice summary of Python version number structure.

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.