Joking aside, I was intrigued by the list of good things at the end of the post. Some I could understand, but some seemed to fall into that strange category of things that people say are good but really seem only to lead to more of the things they say are bad. In this list we have:

> There are actual opportunities for career development.

Does "career development" just mean "more money"? If so, why not just say "there are opportunities to make more money"? If not, what is "career development" that is not just becoming more deeply buried in an organization with the various dysfunctions described in the rest of the post?

> It's satisfying to write software used by millions of people.

Is it still satisfying if that software is bad, or harms many of those people?

I haven't even used Arch on any of my machines but can't count how many times I've found their wiki useful for my workstations, servers and even custom Yocto-built systems. Arch supports many ways of doing a thing, so whatever tool I'm dealing with, Arch probably supports that and documents it on the wiki. And Arch makes few changes from upstream so the wiki instructions are often applicable on any distro. Sure, it takes some familiarity to recognize when something is e.g. Debian-specific and should be done in a Debian way, but as a user fairly familiar with Linux, I often find Arch to be the best source of documentation.

I'm sure it is very configurable, but every visual I've seen of this thing looks awful and not something I'd want to look at while working. But I understand we all have different tastes.

But even in the blog post I'm struggling with 'why?' here. Am I to understand the primary benefits here are improved battery life and increased developer productivity by tests running faster? Is that it?

I travel an inordinate amount and have never found a Macbook's battery life to be insufficient. I struggle to even remember the last time I've used my computer long enough to drain the batter and not be near a power outlet. I work from ski lodges, planes, my car. This has never been a problem for me. Not once. This just feels like a really bad metric to optimize for given a typical developers' schedule and work arrangement.

> On the flip side, we'll get a massive boost in productivity from being able to run our Ruby on Rails test suites locally much faster.

Is this not just a Ruby issue? I don't know what's basecamp or HEYs codebase looks like on the inside, but they don't feel like projects whose tests suites should require a completely different OS or hardware arrangement. I haven't used Ruby in a decade but I do recall it being frustratingly slow. This seemed to be an understood and accepted reality amongst teams that adopt it.

Anyway, I feel like a better 'why you should do this' in order, especially if it is being mandated amongst developers in a company.