Hacker News Reader

Comment by kiallmacinnes | Hacker News Reader

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..)

View on HN

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.

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!

> 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.

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.

This is like using a hammer to mend everything around you.

Reply on news.ycombinator.com