Hello new followers! Monday RubyGems updates: I've been asked "who are the current maintainers of rubygems/bundler?". It's not publicly documented so unclear. Note this is the second time there was a wave of rolling removals, not the first.

Having met with both sides on the current RubyCentral/RubyGems situation, here's my take: - RubyCentral have managed this exceptionally poorly in many ways including removing literally the most active member of the RubyGems organisation by mistake who has declined to return

mirroring body language except it's text so you're mirroring emoji usage instead 🤝

In 2025: Netflix = second screen viewing. Claude Code = second screen programming.

🔥The great advice in these blog posts is rarely said out loud by anyone: www.seangoedecke.com/dangerous-ad... This matches my experience of what I had to learn to get promoted to principal engineer at GitHub. If you follow them: 50% chance you will get promoted, 50% you'll get fired. 🎲

Learning a programming language in itself is neither motivating nor useful. Learning to achieve an outcome, particularly if it's an outcome you actually care about, is The Way. The best way to get started is by "scratching your own itch"; use programming (e.g. Python) to solve a problem you have.

Useful but sad information: it's now almost impossible to review large GitHub PRs' /files pages on Safari. Google Chrome and Edge have much better performance (confirmed known by GitHub employee) so, Safari lovers, worth switching to them to unblock yourselves in these cases.

This buried “Choosing the right type of tasks to give to Copilot “ nugget in @github.com Copilot agent is pretty good advice applicable to most AI agent use: docs.github.com/en/enterpris...

One of the hardest but most satisfying things in software engineering is fixing a bug with no reproduction. Having to read the relevant code, think really hard and try things that don't cause harm and hopefully fix the problem feels hacky but when it works: delightful.

The engineering question that has the most impact: "Is this the simplest way we could do this?" If the answer references currently unresourced future requirements: be prepared to answer with: "YAGNI (You aren't gonna need it)" and try again.

"Choose Boring Technology" by @mcfunley.com is arguably one of the most important things written about software engineering in the last 20 years. I have never regretted leaning into this and regularly regretted myself or others not doing so. boringtechnology.club

🍺 Homebrew 4.6.0 is out! Opt-in concurrent downloads (`HOMEBREW_DOWNLOAD_CONCURRENCY`), early macOS 26 (Tahoe) support, a built-in `brew mcp-server` and lots of other fixes. Run `brew update` to get it. Full details at: brew.sh/2025/08/05/h...

Joel Spolsky's "Smart and Get Things Done" remains best summary for engineering talent. No-one gives a shit how you did in school or what your IQ is if you can't actually ship. No-one cares how fast you ship if you are stupid about how you do it. Move faster, intelligently.

"Well, will you decompose your monolith into microservices just because all your friends are doing it?"

"ChatGPT cannot write better code than a mid-tier engineer" Ok cool I guess I'll ask the mid-tier engineer who is willing to work for £20/month and be on call 24/7/365 to answer my queries in under a minute to write that script for me instead.

GitHub Actions conditional logic best practice: if you have code that runs only on a push to `main`/`master`, on a release, schedule, etc. run as much of it as possible every time.

Some of the best advice I ever got from seasoned OSS leaders was to stop doing work that others on the project could do instead. Step back, let others step up and focus my energy on higher impact problems. This advice proved even more applicable as CTPO of @workbrew.bsky.social, too.

I just released @brew.sh 4.5.5. Normally patch releases aren't particularly notable but this one includes an MCP server for Homebrew (`brew mcp-server`): github.com/Homebrew/bre... Let me know any thoughts or feedback!

And I'm seeing similar extremes in the Research Community when it comes to the usage of AI. Folks wholesale discounting it because of a hallucination, and other folks being like "we use synthetic users and don't talk to humans anymore and the results look credible!" (gell-mann amnesia effect).

Mike! I thought this whole post was SO SMART and really liked your points about the gell-mann amnesia effect (which I had never heard of!) and your points about asymptotic progress. I had to ask ChatGPT to explain your big words to me, but I really liked your thoughtful take 💜

Why will open source maintainers thrive in the LLM era? > They have honed the skill of rapidly reviewing large volumes of unfamiliar or newly contributed code. This skill is useful, perhaps even essential, for effectively leveraging LLM output. Interested? Check out the post:

Wrote a piece for @opensource.org based on my experiences in open source over the last 20 years (!).

Co-founders John Britton & @mikemcquaid.com joined @johncodes.com and @bizza.pizza on @heavybit.com Open Source Ready podcast to share the story of Workbrew. They unpack their journey in dev tools, the evolution of Homebrew, and what’s next for developer environments. 🎧 buff.ly/hqUKLeT

Proud to release Homebrew 4.5.0 today. The most significant changes since 4.4.0 are major improvements to brew bundle/services, preliminary Linux support for casks, official Support Tiers, Tier 2 ARM64 Linux support, Ruby 3.4 and several deprecations.

Proud of this one. Following a Shape Up process to get new features to customers every ~8 weeks. The velocity of shipping is incredible over here.

In the last two years building @workbrew.bsky.social (a remote-first, enterprise Homebrew startup) I’ve hired 5 engineers (and a hybrid PM/EM). This has been my first time being a “hiring manager”.

It's really underrated how much, when building a CLI, it's worth leaning on integration/regression tests that actually run the tool rather than "test" the code in some unrepresentative test environment. These tests have saved me on Homebrew and other projects more times than I can count.

I left GitHub after 10 years to found a startup. After an experiment with IoT devtools, we pivoted and built @workbrew.bsky.social: an enterprise layer over Homebrew (which I lead). 2 years in, we’ve raised VC, built a remote team, and have paying customers. Here's what I learned:

Before you explicitly ask someone for advice/feedback first ask yourself: - do you actually want advice/feedback or just validation on a decision you've already made? - are you prepared to handle your emotional responses if you don't like their advice/feedback? If not: don't!

The "Gell-Mann amnesia effect" (TL;DR: journalists seem uninformed when you have expertise in a domain, informed when you don't) seems to apply almost perfectly to how useful people feel AI tools are in a given domain given their expertise.

The best engineering metrics are those that, if gamed, achieve a great result. "If you measure number of PRs merged, people will just make loads of tiny PRs to inflate numbers!" Yes. Small PRs are easier to review, easier to bisect/revert and easier to deploy with confidence 🎉

Proud to release @workbrew.bsky.social 1.1.0 yesterday. Highlights are 🔐 Policies: keeping your fleet secure and compliant, 🎯 Multiple Default Packages: deploying the right Homebrew packages to the right machines automatically and 🔑 Role-Based Access Control: better admin permissions.

If an open source maintainer is going to take the time to review your PR: please take the time to actually reply and adjust your PR accordingly. Just leaving it open for weeks or months (until a stale bot kills it) is just a waste of everyone's time.

Your boundaries are not "rules" you get to decide that others will always follow. Your boundaries are how you respond when others are unwilling or unable to follow your "rules". Inevitably, people will violate your boundaries. What's up to you is how you react to that.

Anyone else at FOSDEM this weekend? If so: come say hi at the Homebrew booth (or, if I'm not there, email me and we'll figure something out).

If you are an early-stage SaaS startup you have absolutely no business hiring dedicated "devops" people. Pick a PaaS, build something customers want and stop fucking around with your cloud configuration.

Do your team (and yourself) a favour and go look at your last CI and/or deployment runs and ask yourself "which of these things could be faster/cached/skipped"? Now: go do that and live a happier life.

Acquiring users is hard. Homebrew can make it easier. Harness the power of Homebrew to get noticed by developers worldwide. Learn out how Warp, Raycast, and HTTPie leverage Homebrew to grow their reach—and how you can too. workbrew.com/blog/getting...

4 Ways Homebrew Ensures Package Security: 1️⃣ Local tests on formula submissions 2️⃣ Automated audits 3️⃣ Human review from maintainers 4️⃣ Ongoing maintenance & security monitoring Find out more about Homebrew's review process in our most recent blog post: workbrew.com/blog/securit...

Being willing to say "sorry" genuinely, early and often is a superpower. Friends, partners, coworkers and customers all love it. (Being British definitely gives you a head-start on being good at this, though)

Exciting culmination of a few years work: Workbrew 1.0 is out today.

People spend too much time solving problems that may never recur and too little time solving problems that have already occurred multiple times. This was originally intended as a programming take but it applies well to interpersonal relationships (and many other things), too.

I've worked on a few Ruby apps in my career at varying scales (Homebrew, AllTrails, GitHub, Workbrew) and there's been a consistent theme: Ruby is great for moving fast (and breaking things). You need Guard(Rails). These are mine: mikemcquaid.com/ruby-on-guar...

Software lesson from surprising source (PC Gamer4): if ever there was a good one sentence summary of "how to do product management well", it would be this. (sadly, many of the product managers I have worked with in my career cannot do this)

This was a fun and interesting chat about Homebrew, Workbrew and open source "haters".

How hard is it to say "thanks" or similarly nice things to people on PRs? Not even just talking about open source but also to your colleagues. Judging on my career: apparently very hard.

It sucks to talk shit about people behind their back. You know what sucks more, though? Saying how great someone is behind their back and not telling them that directly. Take 2 minutes right now to send a message to someone you appreciate or admire and haven’t told yet.

My "Using 'modern' Ruby to build a better, faster Homebrew" talk from @rubykaigi this year is out: www.youtube.com/watch?v=QDna...

I'm super proud to have spent the last year building Workbrew and it's now open for everyone to try. Homebrew has always been great for developers but it became clear over time how problematic it can be for security and IT teams.

All engineers automate sometimes. Good engineers automate often. Great engineers automate as much as possible while being unafraid of doing tedious manual bullshit, even if someone else's "job", in order to actually get something shipped in a timely fashion.