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”.

The problem with the “fire fast” part of Fire Fast, but Hire Better is that you’re firing people. Hiring then firing someone is incredibly harmful to the fired, even when it’s ultimately best for both sides. Keeping people that don’t belong is bad too, so hiring better is where the focus must be.

Zuckerberg: “We’re just not going to pay for content when it’s not valuable to people. … when push comes to shove, if they demanded that we don’t use their content, then we just wouldn’t use their content. It’s not like that’s going to change the outcome of this stuff that much.”

In other words: we’re going to steal from so many people that if a few complain, who cares?

Using Git revert to ‘hide’ cherry-picked commits - this seems nicer than rebasing in some cases.

Interesting Google extends BIMI to work with CMC as well as VMC - I did not know about CMCs before. Assuming there’s still a reasonable verification process in place - and ideally that a CMC is cheaper than a VMC - this seems a good move.

(I’m still meh on BIMI in general).

Via Spam Resource

Interesting read on the history of git.

Being wary about DRY - the other place people DRY too quickly is tests.

“Your product team can see that Feature A is 250 tasks, Feature B is 50 tasks and that your team completes tasks at an average rate of 40 tasks per week to project a reasonable completion time on their own. Feature A would probably take a little over 6 weeks. Feature B would probably take a little over 1 week.

You get more accurate projections and estimates because you stopped estimating”

You didn’t stop estimating. You moved the estimating to another team.

The rest of the post is a good summary of how story points fail and how to improve on that but at the end of the day, people will still want dates (and maybe now also a change request process)l

Good basic post on dogfooding. I also believe this is critical and something that has been trickier personally in the last couple of years.

“We are sleepwalking into a terrible situation where a few parties have almost complete control over our entire energy supply, while these parties don’t fall under any energy law. We regulate them as if they were a normal website, which means we hardly regulate them at all.” Bert Hubert

Advanced Testing with Go slides and video: quite a lot of good content not specific to Go. (via Ben Hoyt)

TIL the name “Protege effect”, but I’ve definitely seen and experienced this too. Mentioned in this list of reasons why hiring juniors is important.

Good suggestions for evaluating dependencies - I would look at project activity before the code, though, just because it’s much easier.

I also look up the project on snyk (socket is also ok, but I find snyk more insightful), and do some searching around CVEs and security.

Recommendations from people or organisations or projects I trust have an impact, too.

Interesting thoughts on accidental vs. deliberate spending in the context often of open-source funding. The linked splitting the check idea is interesting in too, although these really need big players to get on board to get anywhere.