I think author's use of the word "the" is misleading:

> You don’t need every job to choose you. You just need the one that’s the right fit. [emphasis mine]

You don't need the job that's the right fit. There's more than one. You need any job that fits. (Or that you can make fit you.)

So, if you want to size up the search, let p be the probability that a typical job you apply for will (1) result in you being hired and (2) be a job that fits you. Then the expected number of jobs you must apply to before getting hired to a job that fits you is 1/p. [1]

Say you think p = 5%. Then, on average, you'll need to apply to 20 jobs to land one that fits you.

How many jobs do you need to apply to have a 90% chance of landing one that fits you? If q is the wanted probablity of overall success, then the number of jobs k you must apply to is given by k = log(1 − q) / log(1 − p). So, in this example, k = log(1 − 0.9) / log(1 − 0.05) ≈ 45 applications.

That's a lot of rejections and ill-fitting jobs before landing one that sticks. Which is why it's useful to be persistent and flexible. Being able to make a job fit can dramatically reduce your search.

[1] https://en.wikipedia.org/wiki/Negative_binomial_distribution

I will offer a second positive but more reserved data point. It took me closer to a day to get my custom Bazzite build working.

Switching over to my images using bootc failed because of what I eventually tracked down to permissions issues that I didn't see mentioned in any of the docs. In short, the packages you publish to Github's container registry must be public.

Another wrinkle: The Bazzite container-build process comes pretty close to the limits of the default Github runners you can run for free. If you add anything semi-large to your custom image, it may fail to build. For example, adding MS's VSCode was enough to break my image builds because of resource limits.

Fortunately, both of these issues can be fixed by improving the docs.

> If the normal process leaves things like this to "some other time", one should start by fixing the process.

Adding regular fixits is how they fix the normal process.

This addition recognizes that most bug fixes do not move the metrics that are used to prioritize work toward business goals. But maintaining software quality, and in particular preventing technical debt from piling up, are essential to any long-running software development process. If quality goes to crap, the project will eventually die. It will bog down under its own weight, and soon no good developer will want to work on it. And then the software project will never again be able to meet business goals.

So: the normal process now includes fixits, dedicated time to focus on fixing things that have no direct contribution to business goals but do, over the long term, determine whether any business goals get met.

If you are interested in writing better commit messages on your own, Google's advice makes for a good starting point:

https://google.github.io/eng-practices/review/developer/cl-d...

I also recommend Zulip's guidelines.

https://zulip.readthedocs.io/en/latest/contributing/commit-d...

Thanks for sharing this! This kind of quick and easy grasp one pagers is how this type of things should be done. We should drum it up loud whenever we can.

Hey, those docs for Bluefin are a great introduction to the space. Very well written!

Thanks! Glad they were helpful.

This cluster of launches might not be intentional. It could just be a bunch of independent teams all trying to get their launches out before the EOY deadline.

This model of complexity from the book is very useful:

    complexity(system) =
      sum(complexity(part) * time_spent_in(part)
          for part in system)

Those fees don’t seem unreasonably high to me. I wouldn’t be surprised if the bailiff was operating at a loss given the time it takes to take possession and bring the goods to auction.

It’s in the public’s interest to have mechanisms to quickly process insolvency in a way that attempts to fairly value property. Auctions solve that. If debtors don’t like the outcome, then they should sell the good themselves before it comes to that. Having others sell your property for you is always going to incur an additional cost.

The point is that, regardless of whether the bailiff’s and auctioneer’s fees are eminently reasonable, it will always result in net-negative benefit to society (excepting the bailiff and auctioneer) whenever the bailiff confiscates property whose auction proceeds are less than the sum of those fees. It is therefore contrary to the public interest for the bailiff to confiscate property unless it can reasonably be expected to substantially clear those fees when auctioned.

The introduction of automatic code modernizers to keep legacy code up to date with modern Go idioms is interesting:

> With gopls v0.18.0, we began exploring automatic code modernizers. As Go evolves, every release brings new capabilities and new idioms; new and better ways to do things that Go programmers have been finding other ways to do. Go stands by its compatibility promise—the old way will continue to work in perpetuity—but nevertheless this creates a bifurcation between old idioms and new idioms. Modernizers are static analysis tools that recognize old idioms and suggest faster, more readable, more secure, more modern replacements, and do so with push-button reliability. What gofmt did for stylistic consistency, we hope modernizers can do for idiomatic consistency.

Modernizers seem like a way make Large-Scale Changes (LSCs) more available to the masses. Google has internal tooling to support them [1], but now Go users get a limited form of opt-in LSC support whenever modernizers make a suggestion.

[1] https://abseil.io/resources/swe-book/html/ch22.html

Some context:

> [This is the closing keynote from posit::conf(2025)] about trustworthy data visualization. But it’s also about trust a bit more generally, and how we should think about it in a world where researchers are faking results, AIs are enthusiastically confabulating, and government is destroying data infrastructure.