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