Thought-provoking piece on password hashing, with some history, and an argument that hashing prevented people realising for a long time how bad people’s passwords were. I’m not sure I totally buy that, but maybe, for some definition of “bad”.

Also an interesting thought that passwords should be asynchronously encrypted instead of hashed, allowing research work using the private key. It’s right that you could never get approval for this now, but maybe it would be ok if there was the theoretical room where the keys were stored.

I don’t find this Paul Graham piece on writes and write-nots compelling. For one thing, I think it’s more “write well” than “write”, but that’s not clear. Either way, I’m not really convinced AI is actually going to do this well enough that some aspect doesn’t remain common. Even if “writing well” ends up meaning more of editing and prompting, it’s still a skill people will need.

Fun post on async functionality in programming languages - which is a spoiler, sorry, but it was pretty obvious what “red” and “blue” were very early, and that doesn’t ruin it.

Hard-coding things you can’t mention will be interesting to see scale. (Via Simon Willison)

Worth reading and thinking about: motivation and work - the waste aspect it brings up is so infuriating and it really does need people to just care.

Interesting (and deep) thoughts on async/await both in general and in specific languages.

Good comments on working in tech outside the Bay Area. The thoughts on the future of SaaS are particularly interesting (or least obvious to me, compared to the rest).

As solar power trends towards free or negative cost in places, this kind of practice where you adjust systems automatically with available sun/power will get more and more common, I expect.

This extract data by making it a video and using AI to analyse the video technique is clever and impressive, but also horrific and inefficient and I really hope tech turns back from this future.

“Many rank-and-file engineers have stories about submitting their resignation, or threatening to quit, and their managers plying them with stock or cash or promotions to stay.”

I’ve had this happen to me three times. One worked out really well, and we were both happy for years after. One worked out ok, but didn’t last as long. One left both sides less happy (but with me earning much more and the company keeping me for a while longer).

A lot of good advice (for both sides) in this long post on how long to stay, and how hard to work to retain.

Interesting explanation of why Apple autogenerated passwords look the way they do.

“This proclivity for romanticizing the past and growling about the present appears to be (a) perennial and (b) cross-cultural. It’s also (c) dangerous because it prepares the ground for reactionary practices. That’s true most obviously in politics, where demagogues weaponize nostalgia” Alfie Kohn

Interesting details on how Copilot prompts for suggestions in VS Code - potentially outdated now, of course, butt insightful into what’s happening under the hood.

I really enjoyed this talk on local-first software and ‘barefoot developers’. I agree with a lot of it, although I’m not sure whether generative AI will really have the impact people think it will (plenty of tools were meant to in the past). The call to action, having tooling that supports generative AI builders to guide where it goes, makes sense, though.

(Generative AI has so many other ethnical, environmental, economic, etc concerns as well, so do reasonable uses even survive the bubble?)

Interesting idea to have a Cleanathon, a hackathon where the scoring is based onn removing stuff.

I keep seeing this image alongside people saying that maintainer numbers in Europe are growing. But the numbers are: 113->119->165 for Europe, and 77->34->28 for Asia, with a 22 person increase overall. So the more interesting question is where everyone in Asia is going, at least until it’s clear if 2024 is an outlier for Europe.

(North America is 113->98->131).

A lot of words on dates and estimates but this bit I have found to work well:

At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.

Good arguments against GraphQL, which I always disliked.

Interesting post explaining why str.join(generator) is worse than str.join(list) in CPython.

An interesting theory that a daily standup is for context switching into work mode.

I’m not sure I agree with this, but it at least provides a more compelling reason than “what I did, what I’m doing, where I’m blocked”. It’s interesting to think about when considering what time of day the standup happens.

“Please, get my scrollbar back” 💯

The extra effort to have release notes and a changelog, as described in this post on changelogs is valid, but I feel it’s time worth investing. If you don’t care or don’t expect any other users, just have Git log, otherwise, do it right and have release notes and a changelog.

I agree with this explanation of changelogs vs. release notes, although I think I draw the line on inconsequential changes slightly differently. This last comment:

The difference between a changelog and release notes is the difference between a “reference” and an “explanation” in [Diátaxis]

is interesting, though, and something to remember next time discussing this with Canonical colleagues.

Good changelog guidance, except it conflates a changelog and release notes in my opinion.

I’m not 100% on board withh the git parts of this post on changelogs vs got log but I definitely agreee with “Git commit messages and changelogs have different target audiences”.