going all-in on Linux is one thing, but going all-in on a specific window manager? with specific keybinds? idk, individual workflows are too specific to be prescribed like this imo.
I had a similar thought, but at the same time, if people were mandated to use Windows or MacOS then that would also pretty much lock you into their respective window managers. I guess it feels more restrictive partly because it's more common to pick and choose WMs on linux. (And partly because, yeah, seems like the setup goes way beyond just a distro+WM).
Also because it's a niche WM catering to pretty specific preferences. I used tiled window managers for a while but eventually I decided I preferred the no-customization, one-size-fits-all Gnome/KDE experience. A hyperland config is going to fit like a tailor-made glove—but in this case, it's a glove tailor-made for your CEO, not you.
I spun up Omarchy in a VM just to see what the fuss was about, and when I opened Neovim it booted into a plugin manager and started installing at least two dozen random plugins, including an extremely over-eager autocomplete config that filled my screen with snippet suggestions. I was instantly irritated.
Actually Omarchy is also run by 37 signals so this post is effectively that them saying that they're going all in on the same stack as a group. They can obviously just change what that stack is whenever they want though. This is coming from the inventor of rails so it's not that surprising to see a push for conventions.
I interpreted the push as being partly about Linux in general partly about their customized Hyprland experience in particular.
I doubt there'd be much complaint about a dev who switched to Linux but chose Gnome over Hyprland. VS Code and other tools are going to work the same on either one.
In general I think there's lots of broad optimization possible for developer workflows.
Devs use some combination of the setup/suggested dx from their company, their own preferences/tools, and a large amount of informally socialized tools and setup that other devs at the company use.
Trying to shift deliberately towards a more collectivized experience can help a lot. When one dev goes to work with another, having a stable base to work from can help a lot. Source files tend to be in ~/code, we tend to use rvm for version management, we use Y LLM-tools with Z MCP servers.
Being able to dogfood your working environment together feels impossible & absurd, but leaving everyone out there doing whatever they cobble together feels at least as absurd.
37signals is also sort of home of Rails, where "omakase" and convention over configuration are deeply woven into the lore. The idea of them building something that just works out of the box & is tuned makes hella sense.
Beyond just cobbling together tools, having a practice can help so much. My god I've totally become such a more empowered vim user after switching to astrovim! Yeah the very amazing automatic tool config helps so much. Sure the modular lazy vim plugin experience and the slick as hell astrovim community packs have made layering in new tools & configuring existing ones mostly very easy. But holy heck, astrovim has a visual menu for the leader key. It turns vim from having an implicit depthful interface to an explicit visible interface.
Someone configured all these tools to show up somewhere, made a pattern for walking through tools. It's game changing: having folks make some sensible dev centric defaults and make them visible has made all the difference for me.
https://docs.astronvim.com/#-features