Stories like these are the ones that inspire me the most. People using technology in a way that helps them in their everyday lives, or in a hobbyist fashion. I feel like many of the things I pick-up at work are out of career necessity: the latest framework, bits of an up and coming language that is going to be "the future", semi fluency in a stack so I can aid in a project,I enjoy it, but I don't enjoy it like in the same way I once did.
Probably my favorite programming memory was teaching myself Java as a teenager and building games for my friends and I to play. No responsibility, if they worked...great, if not oh well. It was exhilarating. I do not think programming will ever become a lingua franca, as stated in other places here. I think hobbyist programmers may pop up more and more,or people who know enough to build small tools for themselves (not to scale) and I don't think that's a bad thing.
As one of those hobbyists, I can say that the thing I wish most for was an easier way of "getting started". I mostly hack around in python, or arduino c, but I really wish that it was easier to write a script and actually give it to someone else, and actually have it run.
The feature I like most about excel, is that it is practically ubiquitous. If I give someone else an excel toy workbook that does something, they can run it without needing to "manage the environment". If I write something in Python/numpy/pandas/Jupyter, it is actually pretty difficult to make it useful to anyone. Portability just makes the whole hobby programming thing much more fun.
yeah, I hear that, and I also know in my heart that it's right, but I have no business running access control/distributing my code/or hosting it for public consumption. Mostly a "hey, look at this data analysis" or "this is a good way to do this process" kind of things. emailing someone a file was a pretty good workflow for the low-volume script problem. I wish I could just get a python sandbox for GitHub and have them run it all for me.
This reminds me of the time I used Python to fill out my Wife's 4th grade report cards. She kept all the records in google sheets, so when it came time to do report cars, she already knew what all the grades should be. But the school only provided a terrible app where you literally had to make three clicks with a mouse to enter each grade. Each kid had about 20 grades to enter, and there were 30 kids. That was a lot of clicking and a lot of RSI.
The app had no import/export, but it turned out you could save your work in progress to a proprietary file format. I figured out the format, and then figured out how to basically take the data in google sheets and munge it into the save file format.
It took about 3 hours to enter all the grades manually, and it took about 3 hours to develop the app. So for the first time we used it, it was a wash, but then we got to use it twice more.
Sadly, then they changed report card programs and the new one used a binary file format. At least the new program allowed keyboard input with shortcuts, so it wasn't as a bad.
I've done exactly that for my monthly time reports at work.
The company's official ERP in which we report our monthly activities is a horrendously slow and error-prone old-school GUI, where you basically punch a lot of numeric codes that represent customers and activities, and that can be pretty hard to get right. It looks like a spreadsheet with delays of several seconds after each cell is filled-in, because the apps commits everything over the network each time. I would waste several hours of life every month, typing one piece of rubbish at a time into that sad thing. It's a lot of pain and a colleague had written an automation tool based on the ERP's binary formats. However, his tool needed the code to be adjusted to each user, then compiling his thing was no easy task, then you needed to ask for special permissions to be able to feed the ERP with the binaries, and at last you realized that the binary output was a fragile thing, and so nobody used the tool.
So I wrote an automation script in Python with pluggable input sources which can be combined (text files that are easy to read and write, http connection to Redmine activities... later on a colleague took the tool and added a GrindStone source, and another guy plugged it into his Outlook calendar). The output stage to the ERP is built upon PyWinAuto, and it just simulates key-strokes on the proper window. It is not smart. It remains constrained by the ERP's slowness. But IT IS A HELL OF A FUN TO WATCH your monthly torture getting done all by itself, and enjoying a walk with a coffee in hand for that time, coming back from time to time to see your screen doing stuff.
All in all it took me about a whole day to write the script. It has been running for four years now. One ERP update broke the output stage. Fixing it was a matter of minutes : just write down the new keystrokes.
My clinical training log (requirement for specalist board registration) is similarly frustrating, so I wrote some JavaScript hooks and then used Keyboard Maestro to mostly automate data entry. 9 clicks became Ctrl-9, for example.
RSI seems to have gotten worse as the newer school systems are trying to be touch compatible. They also update often enough to break any useful shortcuts or get swapped for another entirely different system.
I haven't read the article (yes, I know, sorry), but the headline reminded me of a donut shop here in Houston.
I don't know if the sign is intentionally this way, or if the middle letter of the first word in the name fell off, leaving behind the short, horizontal mount point, but either way it amuses emacs folks a lot, because it appears to say:
M-x Donuts
Who among us hasn't wanted, at least once, to invoke that mode?
The very one. It's on the northwest side of the city. This is funny to longtime Houstonian nerds, because that's the area where Compaq was, and where Digital was, and which is now HP I think. (?)
Thanks for sharing! Unfortunately Emacs came into my life after I grew up and left Houston, but if I ever find myself up 249 while on a visit I'll be sure to stop in.
When I was a child, we would always drive past a particular convenience store on our way to my grandmother's house. At some point in history, it must have been called "Self Service Mart," but the first S had long since fallen off. I loved imagining what the staff were like. It's probably for the best that we never went inside.
This makes me wonder what someone with less computer experience would do, ie if you're not a former computer professional.
Sure, open source makes everything rather accessible from a monetary point of view, but you still have to learn things. I almost feel like in the past there were more attempts at making this accessible to the end user, HyperCard, dbase etc, even just BASIC on your 8-bit machine.
Nowadays? Excel/Google Sheets for the most simple case, probably, but if you have to transfer data from/into there or present it differently? Web sites and GUIs aren't that easy, but it's what the users know.
If your point of interaction with a computer is more bare-bones (eg a BASIC/DOS prompt), solutions feel closer, easier to grasp.
> This makes me wonder what someone with less computer experience would do, ie if you're not a former computer professional.
One would simply make bread the same way as it has been done for 1000 years!
Humans can understand ratios, write stuff down, plan for the future, etc all without org-mode in emacs, databases, and sometimes without even a calculator.
Down the street from me is a baker so good he doesn't even have any signage, you have to know it's there -- the line out the door at certain times might be a hint -- and as far as I can tell, other than punching in the prices in the minimum cash register required by law, they keep no records at the point of sale.
I don't know if he keeps spreadsheets or even databases elsewhere -- I hope he does, as he's an amazing baker and works his butt off, and I hope he makes tons of money. But I really don't think he has any record of, say, whether Rye or Spelt sells out faster. (It all sells out every day.)
So I wonder if there's some level of artistry where optimization might just be an annoying distraction.
Yup. Bakeries have been run using a pen and paper daybook and the master baker’s skill for centuries. But the calculations are still a pain in the arse, so automating that is a big win. The Bread Matters spreadsheet I based the database schema on was made by someone who was a baker, not a programmer, and for a fixed set of recipes, it’s brilliant. If I hadn’t known the rudiments of RDBMS design I’d have bitten the bullet, extended the sheet and grumbled every time I had to add a new formula.
I know a lot of financial analysts who don’t know how to “program” but develop incredibly complicated Turing complete excel models regularly. Excel is a very flexible tool and can be leveraged to great effect.
I know for a fact that up until around 2006 the official US Treasury curve for one of the big financial reporting firms was created/maintained on an Excel spreadsheet that was one step away from becoming sentient and asking us if we wanted to go get high.
Can't remember where I read the story, Steve Yegge perhaps. But they were talking about how where they worked secretaries actually used Emacs apps developed by the IT department and, over time, the secretaries started to extend the apps with Elisp.
> Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it.
> People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them.
Ever since reading that essay years ago I’ve been perennially curious about Mailman. Would be really cool to see a screencast or even just some screenshots of what the UX was like.
That's from Richard Stallman. “Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.”
It was Bernie Greenberg, who discovered that it was (2). He wrote a version of Emacs in Multics MacLisp, and he wrote his commands in MacLisp in a straightforward fashion. The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
The thing that has irritated me often is not that people are idiots but they often lack of self belief that they could learn to do something. The key here is the secretaries didn’t realise they were learning to code, but if you told them to learn to code they would most likely make excuses.
We bought a new iSeries mainly because the accounting staff said, point blank, the GUI on the replacement system was total crap. The green screen is efficient and they can get everything done quickly without moving a hand off the keyboard.
Millions of people used WP5, with its cryptic codes and huge keyboard overlays. I don’t believe that’s any easier than Emacs (or HTML). People can figure things out, when they have to.
Cryptic, yes, but discoverable! Recently I was trying to help someone fix their bizarrely broken Word document, and I would have given my right arm for "F5 Reveal Codes."
Yup. It's called a "self-documenting editor" for a reason :). From built-in help on every command, function, variable and keybinding, through apropos and tutorial, through a full-length manual - all available off-line, in the editor - it's easy to get your bearings around using and customizing Emacs. That is, once you adopt the old-school, pre-web notion of software actually having documentation.
You mean the paragraph mark, "¶"? The Show All feature in Word will highlight whitespace, tabs, newlines, which is helpful. But in WordPerfect, Reveal Codes would show much more than that: style changes, image and table introductions, etc. It was much more like looking at the HTML source of a Web page in a Web Developer tool -- not only could you see the tags, but you could modify and remove them easily and precisely.
> I almost feel like in the past there were more attempts at making this accessible to the end user, HyperCard, dbase etc, even just BASIC on your 8-bit machine.
Oh for sure, look at web: we transformed something simple and beautiful like html+css in a complete shit show.
Also, I don't feel like the new programming languages are easier then COBOL or BASIC, quite the contrary. We are making technology more complicated for no reason.
Or at least, at the time we had the very complicated stuff and stuff that simplified complexity. Think about S and SPSS.
Now we have complicated and very complicated. We are giving less creative possibilities to the end user: making them consumers, first of all.
IMO it's more a product of people expecting more from software. It's no longer enough to have something that works; it has to work and be pretty and user friendly.
I wonder who does that. All my experience with non-tech people tells me that they don't expect anything from software, just accept how it is, but they do get annoyed if it doesn't let them do their jobs quickly. Designing for the needs of normal people seems to go in the exact opposite direction to the current UX trends. When UX trends lead to slow, thin, shiny applications, users would be happier with dense and fast applications which minimize time spent in them.
I still miss VB6. It was a beautiful tool and easy to make GUIs with. I still can’t handle writing native GUIs without a good WYSIWYG editor. Delphi was cool, but Object Pascal?! Many people still swear by Delphi and it’s because when your code is UI focused Delphi makes that super easy.
Google Sheets with Google Forms (or whatever it may be called) for some users. Or, without internet, Excel.
The spreadsheet is sort of one of those insane breakthroughs where it really makes programming (functional at that) really easy to grasp. And you can iteratively and intuitively add hundreds of variables and logic gates.
> Google Sheets with Google Forms (or whatever it may be called) for some users.
That was my reaction too. I have a google sheet for bread that allows for different batch sizes and displays out baking instructions in english. This is what a cell looks like: ="mix "&D3*B$1&" grams of "&C3
I can look at the sheet on my phone when making bread. Sheets also now caches off line.
Yup. The spreadsheet is an amazing innovation, I just find all the repetition when adding something that should just be data to be monumentally frustrating. And I have no idea how to make a sheet that copes with orders for Friday and Saturday when a when each batch takes three calendar days. I suppose making a new copy of the basic sheet for each batch would do the job.
There's a decent size (albeit a little bit - but only a little bit - specialist) wholesaler in sydney. The boss is a tech enthusiastic, and the whole thing is somewhat glued together with various bits of perl and other stuff.
I'm trying to help my girlfriend manage the inventory for her cactus business. She raises cacti from seed, cuttings, but mostly from wholesale suppliers. She has a square account and store. I’m trying to set up inventory tracking for her. There are couple of things that make her business different than most inventory holding businesses.
1. Generally her inventory increases in value over time because it grows. Over time a plant will grow from a smaller pot to a larger pot, plants in large pots sell for more.
2. She wants to track which suppliers provide better quality plants (do the plants die quickly?). She also wants to track how fast different plants grow.
I could pretty easily write a django app that tracks this stuff.
Any recommendations for a platform I could build on top of (airtable? google forms+sheets?). Maybe some type of marketing automation platform.
Custom business apps are tricky. As a programmer it's easy to turn my nose up at excel based solutions, but I totally see how they end up being built.
> Custom business apps are tricky. As a programmer it's easy to turn my nose up at excel based solutions, but I totally see how they end up being built.
Both of these are true. And most people do not appreciate how tricky niche apps are. When I started writing PartsBox (for myself initially, later grew it into a business at https://partsbox.io/) several years ago, I thought I'd be done in a weekend. Nearly 4 years and almost 3000 commits later…
Spreadsheets are a pain for anything but the simplest things. And yet they are useful to a point, because making a domain-specific application is surprisingly hard: there are lots of edge cases that you don't think about initially.
This reminded me of the following from The Tao of Programming[0]:
"There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
Hi! I'm David, the founder of Retool (https://tryretool.com). We describes ourselves as "a fast way of building custom internal tools". (That's what's on our landing page, in fact!)
We're inspired heavily by Excel and visual programming. The idea is that business apps — even custom ones — all have the same building blocks for their front-ends: tables, buttons, dropdowns, textinputs, etc. And so we give you all of these building blocks, as components that you can use.
And most custom business apps interface with SQL databases or APIs, so we have native integrations with those. If you want to render a list of users in your app, for example, you could write the SQL query (`select * from users`), and save it as `users_query`. Then, you can drag on a `Table`, and have its `data` property set to `{{users_query.data}}`. Then you're done!
This probably all sounds a bit abstract... so here's a 3 minute demo video, if you're curious: https://vimeo.com/303811211
Let me know if you'd be interested in trying it? I'm at david@tryretool.com if you have any questions / feedback! :)
Back in the 90s and early 2000s there was a good market for desktop apps based mainly on glue languages and an RDB + interface. Most of these were utter crap. From looking at this offering and other (P|S)aaS nothing has changed except the venue.
Django is a decent start. I suggest keeping it as simple as possible, and providing easy export of data to CSV’s or spreadsheets, so she can do reporting and analysis in a more free-form fashion (and you don’t have to build a reporting system).
I'm sure this exists, but it's probably about time we had a GUI you can put in front of a Postgres/MySQL server in a similar way to Access forms, as a kind of hybrid between niche app and off the shelf.
I have only ever been a tech hobbyist, but I have leveraged my Python skills in a similar way. I run a home cleaning service with my wife, and I started using Airtable to track clients, jobs, expenditures, employee hours, etc. The data entry became tedious due to having to make entries in multiple tables for each job, so I wrote a Python script to use a simple command line read-eval-print loop to collect job information and make entries in the appropriate Airtable tables through the Airtable API.
I also use Python to produce paycheck stubs, do simple business data analysis, and email me leads from our website.
A small tangent: I have recently become frustrated with the limitations of a command line interface (primarily the inability to display charts and graphs), but there is a dearth of solid alternatives. Both web frameworks and GUI frameworks add far too much complexity for a solo amateur developer to quickly iterate to meet a small business' needs.
I would love to have a product that let me produce ugly but practical GUIs in Python without having to learn a big framework like PyQT or Django. EasyGUI comes close, but isn't quite good enough.
For now, I update an HTML file to display graphical output in Python and use a Firefox extension to auto-refresh the page on changes.
I've looked at it, but I would be writing hundreds of lines of code just for the interface, which would really slow me down. I really want to be able to focus on business logic and slap together a minimal interface in an hour or so. And unfortunately, I'm not able to code every day, so the more interface cruft I have to wade through, the longer it will take me to dig back into it in the future when I need to make changes. EasyGUI is built on top of TkInter but takes care of all the details to give you a handful of super-easy-to-use basic widgets. It would be perfect if it was just a little more finished.
I have the exact same problem, I've tried many things over the last 10 years and the solution you're using is (imo) by far the easiest, most flexible and robust. It feels hacky but it just works. If you want some interactivity (different graphs in tabs for example) you can just add some jquery or bootstrap - basically a serverless SPA (real serverless, not the 'cloud hosted' thing they call 'serverless' nowadays). I have 'apps' for recipe management, investing, and food forest design that work this way (the food forest one even incorporates Sketchup 3d models and generates a clickmap that lets you click on 2d renders of 3d models to let you interactively select areas using the canvas api - so yes you can make it as complicated as you want, but the easy things remain easy).
I had a similar use case as you for making apps to run on a Rasberry Pi for my staff to use in my business (Chocolab.com.au) I discovered appjar.info which has been so simple to use for quick ugly interfaces. It is built on top of tkinter
As people flock to become programmers, as a population we will become increasingly technologically literate. Sooner or later we will enter an age where programming is as second nature as writing. Communication at the end of the day is a way to get people to understand what we want. Programming is very similar only directed at machines, and as machines continue to replace people in trivial (and not so trivial) tasks, that will be the lingua franca. And yes, it will be javascript.
I think you have a biased outlook, to be honest. For every handful of programmers I know, I know at least 100 others who maybe can barely use their computer besides basic apps.
Programming is still not intuitive (nor enjoyable) for the vast majority of people, and I believe it will stay that way.
I look at how much time (and Friday nights) I sacrificed to get into programming and think life is too short for everyone to be a programmer.
And I don't see why programming has to be the ubiquitous pipedream over any other field, like philosophy. Of course, the main issue is that everyone is different and only a fraction of people are going to have an interest at all in a given niche.
The majority of people can't even do something that is universally uncontroversially good for them like exercise or stay a healthy weight. So I always thought it was funny to think that we'll all sing kumbaya over something that requires effort but with even less global appeal like programming.
Agreed, I think programming as a skill will follow a similar arc to automotive engineering.
Early on it was highly specialized, but from the 50s-80s it was generally expected that you knew how to maintain your car and would do the basic jobs yourself (oil, tires, maybe even filters). But now? A lot of people now would even call out AAA to change a wheel.
Cheap tyre iron included with your vehicle vs nuts over-tightened with commercial pneumatic wrench ... it's not that unlikely that the tyre-iron breaks. If it doesn't you may be unable to loosen the nuts. It's pretty reasonable to call out a mechanic.
If you're doing anything complicated you have to wrangle the vehicle computer.
I expect you're right, computers will get more complex, more proprietary, less open, less likely to use open standards, companies will do more to prevent users adapting or repairing them.
I don't want it to change by much. Yes we need more programmers, but we also need more doctors. It is not practical to become a great doctor and a great programmer.
Those are but two of that millions of different jobs that are required for modern society to function.
> It is not practical to become a great doctor and a great programmer.
> Those are but two of that millions of different jobs that are required for modern society to function.
Who said anything about being a great programmer? We have great writers, and believe me I'm not one, it doesn't stop all of us from gaining quite a bit from writing.
I'm not a native English speaker, I talk french. I'm far from great in linguistic, I'm not even great in English (my accent is atrocious and I require quite a bit of pause when I speak). Yet here we are and we both profit from me using that skill with you.
My sister has a criminology degree and one of her required class was SQL. She isn't a great programmer, yet she was able to use that skill to do more.
Personally I'm pretty sure programming should/will become a basic skill everyone will have. It doesn't means everyone will be great at it, it doesn't means it will fill every needs, but I believe almost everyone can gain from it. How many time have we used algebra in our daily life, I can count it without any hands for pretty nearly everyone ;) yet we all learn it. There so many time though that I saw people do repetitive tasks, that could be automated so easily on a computer, yet we don't learn that at school.
Not everyone will become full time programmer, but almost everyone can profit from that skill.
I think the vast majority of people isn't even aware that programming is a thing. Back when computers used to present people with a BASIC prompt, people had a better chance of finding out about it and getting into it.
These days more people know about it in general because of the high salaries programmers earn. So in time I can see it becoming somewhat similar to wanting to be an engineer, doctor, or lawyer. Except those fields may more accessible even in the future.
I'd say it's the opposite, just like everyone has a car but barely anyone could do the most basic maintenance on it. This is arguably getting worse in every sector because of increasing complexity. (trade off for increasing convenience, as usual)
Familiarity is not knowledge.
I'd even say that technology sets us back because know we're all thinking we're much smarter than we are, I can google any issue I have and find an answer with minor brain usage. I don't need to know how basic orientation skills because I have google maps, etc ...
It's a nice tool for sure, but the only "second nature" we're getting is the "second nature" of googling anything that take us more than 5 seconds of brain time.
I lived without a phone for a few weeks (unwillingly) and I was surprised about how little of my daily life I could still do without frictions.
The only lingua franca I see coming is emojis and memes, not programming languages. That's a nice example of tech worker echo chamber / over optimism / bubble though.
Valid counterpoint. However, we could still be witnessing metaphorical "acne" resulting from instant communication. With no more time-delays or costs associated with communication, the threshold for what makes something worth communicating drops.
What I'm speaking of is not 20 years from now, but 500. When we've moved past the banal, when people have assimilated instant communication but have also learned the preciousness of time and the negative long term effects of information overload. In a way, a bit like how we quickly moved past custom ringtones, but on a much grander scale. Programming is relatively novel nowawadays. It won't be in 500 years, it will just be like a hammer.
Only the future will tell. Maybe it's me being pessimistic but so far tech (for the masses) is mostly used for:
- making money through ads.
- enabling people to live their shallow ego trips on fb / ig / whatever is used these days. (influencers, &c.)
- drown people in endless entertainment to make their work/sleep cycle tolerable.
None of this is helping society is a whole, but, sure we have nice electric cars 90% of the population can't afford and we'll soon send rocket to Mars.
Do we need $2.6k foldable phone ? pizza delivery drones ? same day delivery ? slaves delivering food through apps like deliveroo ? Is that the best we can do with tech today ?
Or is it just enabling our mindless consume / produce cycle with no end goal ? For every meaningful tech advance we have 10 startups raising millions to press a fruit bag [0] or be a rental agency [1].
It's like a sad and lame black mirror episode.
Maybe even longer. It took thousands of years from the invention of writing to everybody being able to read and write. Being a scribe was a viable career path for a long, long time. And even now, most people know how to read and write but do it rather badly. Just a few are actually good at producing and/or understanding text. I reckon the same thing is the future path for computer programming.
Lots of people are already really good programmers, they just don't know it.
I know a few people who are really good plumbers, electricians and general contractors. Basically, they can see a problem and have the skills to break it down and then create a solution.
None of them can type very well and barely know how to use the internet but I bet if they focused on learning the basics of computers they would end up being top notch programmers.
OK, but how many FAANG employees are top-notch plumbers or electricians (i.e. equivalent to tradesman level)? Sure, they may have the potential to develop the skill, but that is equivalent to saying that I have the potential to be a great surgeon. I probably have the dexterity for it, and I'm sure all the information is available through textbooks, but it's a facile argument.
If someone can't even type well, that alone adds what, 80-120 hours minimum of learning just the basic skill alone to get to a level where they can focus on programming without having to focus on input. Specialization exists for a reason, there just isn't the time to learn everything. And the time investment to learn a trade is ~equivalent to the amount of time to learn to program.
Conversely, there are a lot of really good plumbers, they just don't know it.
There's a reason why they didn't be come a plumber.
There's a reason why they didn't become a programmer.
I think this thread greatly overestimates people's desire to do things themselves rather than just consume the products of other people's labor. There are a million things in my own life that I could do but don't.
Some people enjoy their craft (or don't want to sit at a desk all day), in the past few decades programming became really hyped but it's not some kind of goal everyone should try to attain.
At some point we'll have to stop with that "technology can and will solve everything" mentality.
I was just trying to say that there's a lot of general skill set overlap between being a programmer and something like a plumber or electrician.
It's mostly breaking down problems, having a general curiosity on how things work and being able to read documentation. The only real difference between an electrician and a programmer is the context of how they apply those skills.
But doesn't that apply to basically anything in life ?
Everything is about will + tools + problem solving skills. From building a house to fixing a bicycle, building a shelf, fixing an old SLR, &c. I'd even argue that building/fixing material things is more rewarding than programming in general.
The only difference is that current society chose to reward average developers much more than average workers in other industries (good pay, flexible working hours, free snack, job security, &c.). But to me the average developer is not more important than the average trashman or electrician, quite the opposite.
A lot of tech workers are not much more than assembly line workers from back in days, spitting out barely maintainable code found on stack overflow, using tools they understand only on a superficial level (framework, DBs, &c.).
Again, familiarity is not knowledge. We have to stop romanticising our profession as if it was some kind of holy grail, for most people it's just a (good) way to bring money home. Most developers are not revolutionising anything, most are not working on anything meaningful, most are easily replaceable, most don't care that much about what they do, just like everywhere else.
I've read the assertion that the spreadsheet is the first "programming environment" for the general population, and I like the idea. Input some numbers into 2 or more cells and the most basic function would be that the output is the sum of these numbers, displayed in another cell.
https://nodered.org/ offers a drag and drop environment, although indeed the general public would not understand the nodes ("TCP, mqtt, websocket?"), if they could make it more general it would be "easy" to make branches, which is what an if-else-statement is.
It may trend that way for programmers. There's always the time-trusted argument to use a technology that "everyone else knows because maintainability," and often that's going to mean javascript (or whatever language the squeaky wheel likes the best).
But for the general population? I doubt it. We were told, 30 years ago, that everyone needed to learn how to program computers to compete in the economy of the future. That future is here and the majority of people I know aren't interested in learning how to program and don't need to.
The population who currently struggles with its/it's and they're/their/there, basic (con)sequential logic, and even universal remotes is unlikely to become productive in anything like our current text-based languages.
For this flocking to happen, it's going to look more like a spreadsheet, block language (Scratch-esque), or Hypercard type system than a text language. Even there, I don't expect it to become a mainstream activity.
We thought this 20 years ago sure, but I think we have enough evidence at this point that people are going to drool on their iPad playing Candy Crush instead of hacking emacs.
I believe Marvin Minskey was quoted in "The Dream Machine":
> Computers may be a bicycle for the mind, but most peoples mental output is zero. 0 * x is still zero!
Yes, hence my point! I believe we will see more and more of this. Today programming is seen as a skilled art that only the few can comprehend, much like writing was back in ancient times. And so, only a programmer can effectively apply custom technology to non-technical tasks like baking.
In the future, programming will be more accessible, and potentially be so common and part of the upbringing of children that anyone will be able to program simple things they need.
I also see the counter-argument that this is utopian and people will just get more and more stupid. But one can only hope it is not the case! :)
Why must programming be so universal? Look at the number of people who would balk at a simple task like replacing a plumbing fixture or a light fixture. This isn't implying that these people are 'stupid', it just isn't a skill that they have decided is worthwhile to learn. Changing the oil in your car isn't hard to learn, and certainly isn't filtering out the stupid, but there are just a lot of people who simply don't feel it is worth learning how to do. And programming isn't any different--it simply isn't a universal enough skill. Sure, it is essentially required to know basic arithmetic and literacy to function in a modern society, but I don't think that programming is a skill that will ever be on that level.
Maybe that argument could apply to typing, but I'm not sure that even the ability to use a keyboard will be that kind of universal required skill in my lifetime.
> 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 :)
I work at a German IT outsourcing company that builds and runs its own datacenters (but also provides SaaS, ISP services, domains, the whole shenanigans).
We have a central database that was started basically at the same time as the company itself, and now covers asset management, semi-automatic billing, network management (and much more) but is also used to generate configuration for mail servers, web servers, DNS servers, radius, DHCP, etc.
Recently, topics such as revenue forecasts and being useful in compliance audits have become more important.
I like to think that this central database has played a part in the steady growth and success of the company, but it's hard to say without doing controlled experiments (to which leadership would most likely object :D).
This is basically why I end up going back to Emacs. It's waaaaay too easy to start writing functions and the built-in help system (with docstrings almost everywhere for every function and variable) is invaluable.
Though I'm beginning to wonder if JavaScript-based extensions in VS Code can match the power of Emacs code. Are there plugins that connect to Postgres? or do what Org-mode does?
I know it's an oft-repeated gripe here, but Javascript has so many bizarre warts that I'd never trust it to configure my personal computing environment.
I would take elisp over TypeScript any day. The tooling around TypeScript is hot garbage, debugging async code is a huge time waster, and things that are trivial with dynamic binding turn into major undertakings because of the module system. Also the verbosity and reams of boilerplate.
There is a watered down version of org-mode for VSCode. I still prefer the Emacs variety, though. Especially once you tweak out org-capture and custom templates....
Frustratingly thin on details about the actual bakery (perhaps not surprising since it's a blog series). All I could figure out is this Facebook page: https://www.facebook.com/theloafery/.
That's funny, I was wanting more details on the bakery as well. I'm wondering how much of a pay difference he's experiencing going from software developer to bakery owner.
It's nice to work with your hands and produce something, but the margins you can earn with your time are going to be an order of magnitude larger with a tech job than any job involving producing physical goods like bakery / coffee shop / brewery, unless you achieve a lot of scale (distributing your product to large chains or similar).
My longtime buddy owns two combination cafe/coffee shops/bakery (2 units total). He called me yesterday looking for an ecommerce strategy job (which he did previously) since the incredibly low wages, and long hours were enough.
I had a friend who owned a really popular food truck in the LA area. After a couple years he went back to IT work because he could make more with more reasonable hours.
I keep coming back to Emacs reading these stories but it never became a habit primarily I have to work across many desktops/laptops computers with Windows & Linux as well as Android mobile.
Emacs not being usable on mobile is a big problem and biggest roadblock in the path.
I used to run separate Emacs instances on both Windows and Linux, but these days I settled for a different workflow. I keep my main Emacs running on my home Linux desktop. From other computers and locations, I just SSH to the desktop and run an Emacs frame in terminal mode (the command is just: emacsclient -t). Turns out, this is usable for about 95% of things I use Emacs for (the remaining 5% are when I need to view a picture or a PDF, which obviously won't show in terminal). Hell, if you configure your terminal/SSH client to run in 256-color mode, the resulting terminal Emacs will be nearly indistinguishable from the GUI one!
That's one of many hidden strengths of Emacs-based workflow - it works the same whether you're running in GUI mode, or connecting remotely with text terminal. That also means I can work on heavy projects from my underpowered 2-in-1 netbook :).
I have done this before but I like going one step further and running Emacs over X with xpra or similar. An annoyance with xpra in particular last I looked into it is that the protocol version has to be identical on all your machines or it just refuses to connect (it has no concept of forwards/backwards compat in the wire protocol), and debian/ubuntu package different versions, so you end up having to build it yourself locally everywhere.
A mobile interface for Emacs will be killer. I heard about Orgazly and tried using it but it's a very slow interface. A mobile first design even with limited features will go a long way.
Mobileorg was that app for a while but it's development stopped and it's no longer usable.
Agreed. Don't forget about tablets too; I'd happily pay for someone to make Emacs usable with touch gestures and optimized for touch use (e.g. with a clickable, context-aware button row).
I'm waiting for Emacs to run natively on ChromeOS (or Android) so I can get a Chromebook. (I'm not willing to install Cruton or any of the native Linux hacks on a chromebook).
Former CS major, current chef/owner checking in. Restaurants feel pretty ripe for voice assistants/AR but unfortunately lack the necessary technological and financial capital to make it happen, imo. Being able to record and retrieve important information without stopping your work (pulling up and scaling a recipe while chopping onions, for example) saves an immense amount of time in the kitchen. This is especially true during a busy service when circumstances and priorities can change quickly and without warning. The need is there, my question lies in whether an industry with tight profit margins can afford to pay for such a product.
Not a chef or anything, but wouldn't reliability be absolutely necessary with no mistake whatsoever?
I mean, when I ask alexa to play a song, and she gives me the wrong one, it's cute.
If in a restaurant you order 500 kilos of flower instead of 500 kilos of flour, that's more problematic (except maybe on valentine's day).
Same goes for any sort of vocal "note" you would like to make. if it has to be absolutely reliable, I gotta think that voice recognition is not there yet.
This is very true. To combat the problem right now, I have some of my own logic in the middle to correct common misappropriations. I also have a small HUD-like tablet that shows me whatever I'm working on so I can see that the info went in correctly. Your point is still correct: the tech isn't quite there yet to do it without these other pieces.
Yeah, named timers are A+ and also having basic math functions at hand is great. We have a couple different tasks that need to be started at a certain time each day, so we also have reminders that go off at said time.
I guess one of the main challenges is making things reliable. Voice assistants in their current form in loud, stressful environments sound like a source of endless frustration.
> The need is there, my question lies in whether an industry with tight profit margins can afford to pay for such a product.
If it actually saves time and helps fulfill orders quicker, why not?
This is true. I have tried wearing a mic to help with this and have seen some success.
When I say afford to pay, I'm thinking of all the development time that has to go into it to make a viable product. I do believe it is possible and honestly hope to be the person to do it. Even if I'm not, I hope someone does because there is plenty of potential beyond what I'm trying to do.
It's a pity that I read the title first, because when I read the recursive descriptions I immediately thought about a Makefile that emitted directions, cumulative timing, and optional ingredient debit entries for an ordering system.
Is there a name for small(ish), self-contained programming environments that offer optional but well-coupled guis/tuis? I realize this is a gray area, because someone will point out that Tk and SQLite can be slapped on basically anything; but I'm thinking of systems more like Hypercard, Tiddlywiki, Jupyter, Org-mode, even Racket or Picolisp.
Edit: I should clarify that when I say "small(ish)," I'm referring to the number of discretely moving pieces and dependencies, not to, e.g., the size of a binary, or how many batteries are included, etc.
I'm going to be the unfortunate hater, but it sounds like he should spend more time on actually learning how to be a baker and less time writing code in this particular case.
This is what I'd imagine most of the people on here would fall into the trap of when the monthly 'I want to quit and work with my hands' post comes up. It's the cliche, I want to disrupt the industry before I even learn it.
My girlfriend works at a bakery and I showed her this post and asked her what she thought about it. None of the bakers need to write down anything or make spreadsheets on how to make a loaf of bread or any of the other products they make every day. This is like having to google 'how to write a for loop' even though you're a programmer.
Bakeries make the same things every day, there's very little change even though as a customer(me) it might look crazy. Knowing recipes and quantities and how to adjust them are the most basic requirements of the job.
Huge props to this guy for doing it though! I hate making negative posts shitting on someones venture. If this is what makes it more fun for him, then keep doing it, and get better.
You have a point. If I were doing higher volumes at retail, the thought process would be much simpler. Make up a 60% starter on 8kg of flour in the evening. In the morning, empty a 16kg sack of flour into the mixer, chuck in 500g of salt and 12kg of water at an appropriate temperature to finish at 21C. Mix on first speed for to a shaggy mess (about five minutes), then about 8 minutes on second speed to moderate gluten development. Bulk ferment in a cool part of the bakehouse for 3 hours, with 3 folds 40 minutes apart, scale off large and small loaves, shape, prove until slightly underproved (4.5–6 hours) then retard overnight. Back in the bakery at 4 the next morning and, bake everything off and get it to market by 8am.
But today, my customers want 9 large multigrain loaves, 4 small ones, 3 really small soup bowl loaves, a dozen large white sours, 5 small and a couple of dozen bun loaves. On Friday they will want substantially different quantities. If I want to keep selling 95–100% of everything I bake, then I need accurate quantities, and I’d rather offload that essentially trivial calculation on a tool that gets it right every time. Five minutes after I arrive in the bakehouse, I have an accurate production sheet with the right quantities on it and I can concentrate on the far more important task of actually making the bread. I’ve spent maybe a couple of days, over the last year and a bit implementing the production planning software. Time well spent, I reckon.
May be you got it backwards: people who can't deal with numbers have to stick to the same routine. They can't afford the flexibility, the optimization.
That's what I was thinking too. Perhaps this guy has greater aspirations for his bakery and laying out the foundation like this from day 1 will enable him to grow without many of the pains you might otherwise experience when expanding your business.
I don't think he's doing anything that a large scale bakery wouldn't also do, just on a smaller scale. I mean, some outfit that ships baked goods to retail stores all over a metropolitan area. They need to control parameters of the production process to ensure consistency at scale, plus handle all the logistics of scheduling all the processes and delivery.
Every single person that I've met that is a huge fan of Emacs has also had a tendency to get stuck in the technical aspects of things rather than seeing the bigger (non-technical) picture. This isn't meant as flame bait, I genuinely mean that these people have all been very intelligent, but they have all shared this peculiar quirk of absolutely over-engineering things to the point where it's kind of amusing. Your comment made me think that this is exactly how that kind of person would approach baking.
This. Being able to run easily selectable scripts on pieces of selected text in my editor is what keeps me in vim. Doing repeatable tasks, filling XML data, gosh, I even keep my odometer book in vim via small hacked together python script.
People keep recommending things like Visual Studio Code, but I am yet to find a way to do it there... Is it even possible?
I wonder if there's room for a software deployment model for SMBs. Create a GUI on top of Ansible so customers can configure their build, build/deploy a software tarball to a VM, and provide data and code migration tools to your local community colo - all open source. Company offers upgrades, security patches, operations/customer support, and occasionally new features - no mandatory subscription fees, no forced cloud-native stack, and no VCs demanding 20x returns. Something friendlier to programs than Microsoft Excel and XP, and friendlier to SMBs and end users than Slack and G-Suite. Almost like a neighborhood Red Hat, with shims for toy shops, bakeries, and bookstores.
I think a bootstrapper could pull it off, or a small team of two/three funded by a friendly angel.
If anybody is looking for an industry to disrupt: manufacturing, inventory, and logistics software is a complete disaster right now.
I pay $X,XXX a year for manufacturing software, and I just had to write software like OP for my own company.
The software I buy can turn product demand into ingredients and orders. But it can’t do it into the future. So I had to write custom software to take a sales forecast, turn it into a production forecast, and then turn this into a purchasing forecast. Seems like something that should be a solved problem, but not really.
A little bit of know how goes a long way towards process improvement. When you have what process improvement looks
like forced down your throat, mostly contrary to common
sense, is when you know you work in enterprise software.
It’s great to see smart new inventions being made when programmers switch to a, seemingly, extremely low-tech business. Are there more examples of programmers who made a similar leap?
Former bread baker turned programmer here, I wrote a crude side project app a while ago called geekbread http://geekbread.com/. It just does basic bread formulas.
There is definitely a lack of good baking software in the industry. all the spreadsheets I saw when I worked were overly complicated and error-prone. Maybe one day I can expand on the app and work with some bakers on it :)
I see that I'm not the only geek who likes baking. When I was a PhD student I seriously considered packing it all in and starting a bakery. I'd just discovered what seemed like the forgotten secret of good bread: time. At the that time in the UK most bakery bread was terrible and bread recipes in books or online called for short rises in warm places. I had to go back to older books to discover the secret.
I would have been ahead of my time if I'd actually gone through with it. These days it seems that the secret is out again with recipes calling for 6+ hour rises. In the town I used to live there is a very successful artisan bakery now.
I notice recently that the hipsters over on Metafilter are trying to smear bread bakers as "brogrammers" and "neckbeards". What is wrong with them.
And you are right about the rising time. I do an 8 hour rise. Doctor Carrie Reams said that the rising time breaks down the phytates which in turn releases the calcium into a form that the body can digest. 2 hour rise doesn't do that.
Using emacs with 7 million keyboard shortcuts to accidentally press, and then... lisp!! No thanks. This would be more approachable in an Anaconda notebook.
It. Doesn’t. Matter. Use the too, you’re comfortable in and you’ll be way more productive than dropping everything to learn something new. Do that when the limitations of your current tool start to grate on you.
Well, parent's arguments were kind of dumb. "OMG keyboard and lisp" is not the same as saying that one can achieve the same thing in a tool one's more comfortable with.
> Use the too, you’re comfortable in and you’ll be way more productive than dropping everything to learn something new.
That's not true, and this kind of thinking can be dangerous to your productivity - especially if the tool you're comfortable in is one of the new breeds of popular applications or SaaS. Each tool has a productivity ceiling. Software like Emacs or Vim has that ceiling somewhere in the stratosphere; a typical web-based tool has the ceiling ridiculously low, barely letting you stand up. On that spectrum, dropping everything and learning a tool that gives you more space to grow does pay off very quickly.
Probably my favorite programming memory was teaching myself Java as a teenager and building games for my friends and I to play. No responsibility, if they worked...great, if not oh well. It was exhilarating. I do not think programming will ever become a lingua franca, as stated in other places here. I think hobbyist programmers may pop up more and more,or people who know enough to build small tools for themselves (not to scale) and I don't think that's a bad thing.