Disclaimer 1: This post is 100% inspired by DHH's recent references to Omakase and the projects that implement this concept: Omarchy, Omakub. So if you believe this article deserves some "kudos", they should primarily go to him - well deserved.
Disclaimer 2: I've mentioned this several times in older posts - naming things is a superpower. Once named, the concept becomes easier to frame, adopt as part of a ubiquitous language, or even a foundation for mental models. You may have the impression we're not talking about anything new here, and you're absolutely right. But the thing is - did anyone name it before?
I've been building software for a living for a long time already, but certain things remain unchanged. One of them is that engineers are obsessed with their freedom to choose the tech stack and tooling. Programming languages, frameworks, libraries, build systems, deployment mechanisms, observability tools, but also: terminal emulators, Unix shells, IDEs, or even keyboard shortcut mappings, color schemes, and monospaced fonts. Yes, we're all nuts - myself included, guilty as charged.
In some cases, it doesn't matter much (think colors, keybindings, and so on). But in some other ones ...
Omakase
It's a good moment to explain the concept of Omakase. The word's origin is Japanese, and it means letting the chef (in a restaurant) decide what you'll get, instead of picking the dish(es) by yourself. Why would you do that (limit your own autonomy)? Well, isn't he (the chef) an expert who knows best ...
- What are the dishes, and which ones are worth recommending
- How do they fit each other and the extras (drinks, desserts)
- What combinations are optimal (due to flavor synergies)
Apparently, this concept can also be applied outside of the gastronomic domain. One of the founders of 37signals (creators of Basecamp and Hey), David Heinemeier Hansson, has recently been very vocal about Omakase and started opinionated setup projects for a Linux work environment (Omarchy and Omakub). The goal is to provide a macOS-level user experience, but on Linux. And the way to do that is by sacrificing (at least partially) the traditional Linux flexibility (configure absolutely everything from scratch, even if it means compiling things from the ground up), and introducing a high-quality Omakase setup instead.
Whether this attempt is successful or not, I'll leave it up to you to assess (I have my own opinion, as I've tried Omarchy already). But why should we deprive ourselves of the privilege and pleasure of setting up, fine-tuning, and optimizing (for our own, unique personal needs) our workstations? What's the point?
The answer is Omakase - let the chef decide.
In this case, "the chef" refers to the team that handles the project (Omakub, Omarchy), and their full-time job (I'm simplifying, as it's open-source) is to create a top-notch work environment, so you don't have to. You can focus on your own products instead.
Perhaps you could create a setup that works better for you specifically. 1% better, 2% better, or even 5% better. But how much time would you need to build the expertise necessary (including the market research, configuration/customization deep-dive, etc.)? And to maintain this setup (as things do change all the time - new, better tools appear and some old ones get abandoned/obsolete) by yourself? You're not a chef, but a consumer - let the chef decide.
Moving further
However, I don't intend to dedicate this post to convincing you to use an opinionated work environment setup. In fact, I'd like us to move a few steps ahead. Why don't we apply Omakase to our tech stacks in general?
I've met many organizations that "let their teams decide". Some even went as far as letting their team decide on which programming languages or cloud providers to use. I've seen small teams (not larger than eight people) that used three (very) different programming languages in their codebases (I mean: for the same purpose - building APIs and business logic; it would be more understandable if it were: HCL for infra, Python for back-end, and TS for front-end).
The justification was always the same:
- "It's we who work with this code, so no one should meddle with our choice here. We know what will work best for us, and we always pick the optimal tool for the job."
- "Any forced constraints here would impede our creativity. And it will be a clear signal that we don't have autonomy to deliver results - how could we embrace real 'ownership' then?"
I've never seen it end well ...
- The cost of upkeep was massive (due to several implementations of cross-cutting concerns and "rough edges"/incompatibilities between the stacks)
- The operational cross-team flexibility was significantly reduced (sharing work or moving people didn't make much sense, the teams didn't even want to understand each other's code), and so was collaboration (the surface for common standards and conventions was limited)
- The lava flow effect was common - teams were "trying things" out of control, introducing the ambiguity between "new way" (of doing things), "old way", "even older way", and so on - there was never any proper, full clean-up migration of old solution - there was always enough time only to try the new thing, but not to deal with the old one ...
Paradoxically, diving head-first into the newest and shiniest rarely yielded any positive outcomes. Development in Rust was significantly slower than in Python, and even though the compiled code was much faster than the interpreted one, the actual latency was largely caused by the network round-trips. The OLTP state, smeared recklessly across several DBs of drastically different characteristics, could never be fully reconciled. And so on, and so forth.
Omakase all the things
Let's face it. Autonomy to pick tech was nothing but an employee perk in the ZIRP era, when it was the employee's job market and all tricks to attract the candidate were on the table. There was no other valid justification, and those times are now over.
What is more, it's empirically proven that the choice of tech has a minimal impact on the final success (or lack of it) of the company in the end (except some particular deep-tech cases). Just pick something popular that is not in its "swan song" period. Python, JavaScript, Java, Ruby, or C# will do (but just one, not more). There are many "good enough" solutions, so don't look for the perfect one - the consistency and discipline always bring more benefit than frantic tweaking. The boring tech manifesto is still valid.
Go full Omakase. Let the CTO decide. Or the chief architect. Or the technical founder. It's their job to know the needs and match them with a pragmatic stack that can fulfill them. They are literally paid for that ("the machine is well oiled"). Optimizing DX (Developer eXperience) on a limited, unified stack is still much more economically viable than multiple teams' half-arsed attempts to polish the rough edges of what they've independently cooked.
Omakase always scales better. Henry Ford was Omakase ("if I had asked people what they wanted ..."). Good SaaS platforms are all Omakase. Companies fool themselves ("our invoicing process is unique", "we need a custom CRM", "our support processes have to be tailored to our needs") - but this is (almost) always self-deception: they should go Omakase, and acknowledge the fact: the chef (the specialist who does that particular thing full-time every day) knows better.