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.

For example, if you do `git commit` and then `git push`: commit locally and skip only the push to build confidence everything else is working.

Another example, for release workflows: tag in the workflow and only `git push` the tag after you've confirmed everything pasts tests, builds, etc.

"I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re 15 and 35 is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're 35 is against the natural order of things."

Douglas Adams predicted some of the knee-jerk negative reactions to LLMs.

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 and cofounder of @workbrew too.

I just released @homebrew 4.5.5. Normally patch releases aren't particularly notable but this one includes an MCP server for Homebrew (`brew mcp-server`): https://github.com/Homebrew/brew/pull/20041

I discuss building this PR in particular with LLMs and my approach a bit in my recent post about why open source maintainers thrive in the LLM era: https://mikemcquaid.com/why-open-source-maintainers-thrive-in-the-llm-era/

Let me know any thoughts or feedback!

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:

https://mikemcquaid.com/why-open-source-maintainers-thrive-in-the-llm-era/

On challenges:

> Too many open source users are overly entitled and think a bad bug is an excuse to be rude or demand a quick fix. Sometimes, things can get darker still with things bleeding into personal abuse and harassment. I once had someone say they were going to turn up and harass me at a conference talk I was giving. I’m lucky enough to not be threatened by stuff like this but: it’s completely unacceptable behaviour in our community and we should be more aggressive in shutting it down.

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.

Read the release notes at https://brew.sh/2025/04/29/homebrew-4.5.0/ and discuss on Hacker News at https://news.ycombinator.com/item?id=43830153.

@workbrew 1.2 is released 🚀

📦 Default Packages are now free
🔒 Auto upgrades and more policy controls
🔗 MDM device group syncing
🧭 large UI improvements

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.

https://workbrew.com/blog/workbrew-1-2

In the last two years building @workbrew (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”.

I had designed the initial engineering hiring process at Mendeley and interviewed the first ~5 engineers there. At GitHub I was involved in interviewing around ~50 engineers.

This post explains how I interview and why I do it how I do:
https://mikemcquaid.com/how-and-why-i-interview-engineers-for-workbrew/