> The key insight is that a bakery formula is so cliched that it can be represented as data. Here’s the formula for seedy malt loaves:
> Of course, that’s not the full set of formulae, because it doesn’t tell you how to make ‘Seedy malt dough’, but that’s just another formula, which consists of flour, water, starter, salt and a multiseed ‘soaker’, where the starter and the soaker are the results of other formulae, which are (finally) made from basic ingredients1. I did consider reaching for the object oriented hammer at this point, but thought that I might be able to do everything I needed without leaving SQL.
There's no way you can do something similar with spreadsheets? The example wasn't in enough detail for me to understand why not. The jump from spreadsheet to SQL seems massive in terms of ease of use.
There is a downside to this though .. For this bakery, if you hire someone, theres a reasonable chance they can use a spreadsheet (maybe not add new recipes etc, but use..). I'd bet is very unlikely the same will be true of SQL and emacs.
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.
> The odds of the next baker you higher knowing SQL and emacs? Pretty low... the odds they know Excel? Probably higher.
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 odds of the next baker you higher knowing SQL and emacs? Pretty low... the odds they know Excel? Probably higher.
> 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.
I do teach non-tech people computer stuff from time to time in professional capacity, including in the past the Microsoft Office suite, as well as Photoshop, Corel and Inkscape. So I do have a concept of how difficult that is.
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.
SQL gives the developer an option to build a front end of some sort, though, which might be able to get the ease of use to a similar level to that of Excel.
Based on the description of how it works, all of the business logic is baked right into the database. With this design, it should be straight forward to build a front end in something like Flask or Rails since all of the hard business logic is already done. And this would not break his current emacs workflow at all.
> The odds of the next baker you higher knowing SQL and emacs?
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!
Well, he built the system, Emacs is the front end. It's just an awkward front end for most of the people, but with proper training, anyone can pick it up, it's not like ask them to maintain the system.
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.
Honestly, I'm not so sure. Emacs isn't known to be user friendly, I can easily imagine many non-techies simply refusing (consciously or, more likely, unconsciously..) to learn it.
Turn on CUA mode to get the traditional shortcuts, don't hide the menu bar and toolbar - and now Emacs is being operated exactly the same as any other programmer's text editor out there.
The reputation of user unfriendliness is undue, and based mostly on looking at how pros work with it.
For the actual business of making the bread it’s a matter of printing off a single production schedule for the day and taking that into the bakehouse. Touchscreens are a hygiene nightmare in food prep areas.
I'm not saying it's the wrong approach, I'm saying I don't understand what the problem is. The initial example to motivate moving from a spreadsheet to SQL is only this:
recipe ingredient quantity
Small Seedy Malt Seedy malt dough .61 kg
Large Seedy Malt Seedy malt dough .92 kg
Having to tinker with recipes in SQL sounds really bad as well compared to editing a spreadsheet even if you were an SQL expert.
Yeah, he didn't explain that part well. Bakers typically have ingredients in terms of ratios with respect (usually) to the mass of the main flour. There could be up to a dozen ingredients (sometimes just 3) with time and temperature sensitive processes. A typical small artisinal bakery will have a repertoire of a couple dozen baked goods. It's a fair amount of stuff to keep track of especially when you throw planning/scheduling into the mix.
One doesn't need anything more than a notebook (a paper notebook that is) to do this stuff, but to each his own.
Yeah. Lots of hand waving in the piece because it was a choice between something I could write in a morning for a general audience or, frankly, not bothering to write anything at all.
A bakery formula is an acyclic directed graph running from top level “product” nodes (a loaf of bread, say) through one or more intermediate formulae until you reach basic ingredients. For a given set of orders, you need to work out how much of which ingredient to mix at each step in the process. If I were only working in, say six loaf batches, it’d probably be easier to use a ready reckoner approach, but it’s a tiny bakery and I’d rather not deal with the wastage so I only bake what’s ordered.
After about the third time I fucked up the pencil and paper calculations, I decided to automate (then at least the bad calculations were repeatable, and only needed fixing once).
I'm so glad to see other people think of recipes this way. I have so much trouble keeping track of what's going on in a complicated recipe because of the linear way it's written. I have good results rewriting them as a DAG on an index card (or the back of the recipe card) and just following that instead of the recipe.
I really should learn that. I often find myself maniupulating text data in emacs, turning it into CSV or something that I can then copy/paste into a spreadsheet for calculations.
You should. It's surprisingly good. You won't get pivot tables (at least until someone codes them up, which isn't out of the question in Emacs community), but for regular calculations it's awesome.
And if you feel that TBLFMs are getting unwieldy, here's a bunch of features I absolutely love: https://orgmode.org/manual/Advanced-features.html. Turning on an extra column lets you name columns and cells, and have Org Mode recalculate the table automatically on any change, instead of on explicit command.
I didn't know about calculation marks, thanks for sharing! I use org spreadsheets to keep track of my D&D party's character sheets, so this should definitely come in handy :)
> Of course, that’s not the full set of formulae, because it doesn’t tell you how to make ‘Seedy malt dough’, but that’s just another formula, which consists of flour, water, starter, salt and a multiseed ‘soaker’, where the starter and the soaker are the results of other formulae, which are (finally) made from basic ingredients1. I did consider reaching for the object oriented hammer at this point, but thought that I might be able to do everything I needed without leaving SQL.
There's no way you can do something similar with spreadsheets? The example wasn't in enough detail for me to understand why not. The jump from spreadsheet to SQL seems massive in terms of ease of use.