In tech/development, it's akin to someone building a system in some obscure language, because they are most productive and the only ones developing it today.. It's likely that system will end up being entirely replaced if the team maintaining it grows.
(To be clear, I'm not saying the Bakery made a bad choice, or what using obscure languages is a bad choice, or that optimising for immediate productivity through familiar - to you - tools is bad.. just that there is lots to think about when building a new system..)
Choose tools that are: (1) right for the project (2) right for the current team (3) right for the future team
(3) might be hard given you don't know who joins later, and the engineers might also not have a say if they're not involved in hiring. But you can generally make decent guesses. The odds of the next baker you higher knowing SQL and emacs? Pretty low... the odds they know Excel? Probably higher.
With that said, this was still fun. I enjoy seeing technology used in interesting ways, even if I don't think it's necessarily the most sustainable way to do something.
For new formulas, yeah, It's hard to input new formulas, even in spreadsheet. The system is somehow complex, you probably need a UI for new formulas too, even if it's in spreadsheet.
Maybe he'll be looking to hire another person like himself, moving from tech - I'm sure many (most?) of us have toyed with the idea of becoming a baker, cook, farmer, cabinetmaker, wainwright, shipwright, etc. Blog posts like this certainly don't help!
Odds that you can teach them the basics of SQL and Emacs? Pretty high. At the level needed here, it's just UI like any other. Journalists are routinely taught SQL as a part of their studies, and secretaries and writers are known to use Emacs.
As for your points for tech projects, I really dislike the emphasis on (3). It sounds reasonable from business perspective, but business is always hoping for candidates who already know everything they need to be 100% productive from day one. It's an impossibility, and structuring your workshop around such requirements only drags your project down - because instead of using the right tool for the job, you end up using the lowest common denominator tool.
It's kind of like refusing to use excavators, because not everyone knows how to operate them, but everyone knows how to use a shovel and shovel wielders are cheaper.
The reputation of user unfriendliness is undue, and based mostly on looking at how pros work with it.
> Odds that you can teach them the basics of SQL and Emacs? Pretty high.
Have you ever tried to teach a regular person how to use Excel? The above reads like satire if I'm honest. Even teaching someone how to use Emacs alone would be seriously pushing it.
That said, in context of work, it's even simpler. A few tasks, a program. You teach people by example. Type this here, type this there, do this, do that, you're done. Nothing hard.
Think of it this way: almost every company that uses computers has some custom assortment of SMB tools and SaaS websites specific to the job at hand. It's normal that people learn this, and they have zero problems with it. Hell, typical ecommerce management panels I see people working in have UX an order of magnitude worse than Emacs.