Interesting stats on security report volume and response frequency for PyPI
I don’t really agree on the linear trend being used on the response time chart. Eyeballing it, it looks like linear upwards until May (the suspension weekend), then a flat period for a while, then a new linear upwards trend from late June.
My thoughts on return styles triggered by some work today.
I wrote up my experience at Kiwi PyCon over the last weekend - in short: since I’m not hugely into the social/networking aspects, it was pretty disappointing - not enough talks of the nature that I’d enjoy.
(Some other people seemed to be having a great time, although that also seemed a little clique-y).
Good tips for beginning programmers. I especially like “More languages isn’t better … Don’t measure your progress in number of languages. More important is to learn new techniques (database, web, testing,concurrency, etc.) in the same-old language”.
Interesting use of LLM in teaching history that relies on the generated text being inaccurate.
Public (and more extensive) post about the problems with review sites that I posted about (when it was in a member-only post) last week.
Good summary of what CNAMEs are, and why they often cause trouble. I’ve seen people have mail issues due to CNAMEs many times.
Canonical uses Diátaxis, so I’m learning a bunch more about it while onboarding. These thoughts about where it falls short were interesting in that context.
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.
“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.
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.