Comment by rahimnathwani
7 years ago
"There's no way you can do something similar with spreadsheets?"
You can, but the author is using tools that are more familiar to him, and hence more productive for him.
Just like when doing some quick and dirty analysis, some people will reach for Excel, some for R, some for Pandas. None of those people is wrong.
Some people go too far the other way: spend too much time learning new tools, and not enough creating things of value.
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..)
This is a very important point.
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.
3 replies →
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.
1 reply →
> 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.
1 reply →
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.
This is like using a hammer to mend everything around you.
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:
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).
1 reply →