Good thoughts on using employees vs contractors vs consultants. My one disagreement is I’ve never really had great experiences with contractor firms, but lots of them with individuals.

(I’m reading here, as JKM intended, “employee” by the meaning, not the label, ie. like AoNZ law, and not like many company contracts).

More posts on managing through layoffs would be interesting to read. I’ve only really been through this in any significant way three times (once being me) but they were all hard for many people.

Interesting thoughts on hiring for floors, not ceilings. I find it’s easier to raise someone’s floor than their ceiling, too. On the other hand, where I’ve had a team with no-one that has a high ceiling, it’s struggled - I think having someone that can stretch pull everyone else up closer to their personal ceiling.

Simple wildcard DNS tool rather than editing local host files. Seem very handy. Found via Canonical onboarding docs.

“The next problem is the idea that you can get a lot of things ‘at once’ and test them against each other, thus reaching some definitive conclusion. In doing this, you root out the bad, but you don’t/can’t hone in on the good. Why? Becuase the difference between fine, good, and best is in the nuance. You only experience nuance with extended use.”

This and more insightful thoughts in The Brooks Review (🔒 members only) this week.

Good summary of object immortalisation in Python (3.12+).

“The way trust gets rebuilt is by ✨small, positive interactions✨. If you’re in a trust hole, you can’t hear them clearly, and they can’t hear you (or your intent) clearly” - good suggestions for building (back) trust.

Interesting post on ‘int age’ vs ‘age : int’.

I’ve written much more code in ‘type first’ languages (especially C, C++, and Javascript, but also C# and Java) so it seem strange to do ‘name first’, but I agree with Ben that it makes more sense.

I suspect that this ‘it’s about the real estate’ take on anti- remote work is indeed part of the story, both here and elsewhere.

This is a really great primer on Unicode. I think a lot of people really do underestimate a lot of the challenges, which is why software has so many weird edge cases. US- & UK- centric dev doesn’t help either.

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.