> Software is trivial to make for yourself and insanely hard to make for someone else, so your vision is not completely off.

No idea how true that is, based on my own experience - totally false. E.g. writing the control software for grow lights (esp-32) was far from trivial and my daily job that's actually writing software "for someone else" is not hard.

I think you just chose a hard way out of habit :) If it were pi-like platform instead of esp, you could just ssh and vi new “gpio …” lines into your crontab (depending on how the lights are connected). I dealt with esp before too and it’s really of “8-bit++” kind, missing all the power of software we built in recent 30 years, so you have to reinvent wheels too often. The only reason these platforms still evolve is they are much cheaper if you plan to ship thousands pcs or make them work in limited environments.

It's easier to control your grow lights than to write the equivalent for someone else. All the unspoken assumptions about how the system ought to work are yours. Therefore you don't have to fill in the gaps of someone else's attempt at describing what they want.

Technically I did it for my spouse and her flowers [grow lights did require designing and soldering all the power and electronics control circuits - which admittedly I am less verse than writing code], but again I can't quite see the difference between my daily job and personal projects in terms of understanding the matter. If anything personal projects have less room for failure as by their own definition are quite more ambitious.

While there is no intrinsic care about scale, running it remotely, no downtime, APIs misuse, etc. - it's very much the same process with writing, debugging, refactoring, deploying and so on.

> to program this toy, first you have to learn emacs and elisp

Yeah, thinking about f---ing in the context of emacs makes me want to vomit a little bit. It's about as sexy as RMS' underwear.