Code For Hackers

Mike and I were talking about two very similar clock projects we’d both built recently: they both use ESP8266 modules to get the time over WiFi and NTP, and they both failed. Mike’s failed because he was visiting relatives in a different timezone with different WiFi credentials, and mine failed because daylight savings time caught me off-guard. In both cases, we hard-coded stuff that could obviously change, but we drew vastly different conclusions.

Mike thought he’d solve his WiFi problem with a fallback to a captive portal, and maybe would have to figure out some web interface for configuring the timezone. A very clean, professional solution. Me? I’ve got good comments in the code, can find the UTC offset (or the WiFi creds) in a few minutes, and flash the new version up simply by fetching a USB cable, for something that happens twice a year. It’s hardly worth the trouble to cobble together a web interface.

There’s an XKCD for everything.

We’ve accidentally embodied a quandary that spans both the hardware and software worlds: should flexibility be exposed to the end-user or to the hacker who can peer under the hood or open up the source code? (And what if the end-user is the hacker?) What are the tradeoffs, in project complexity and in ease of use?

And in this, Mike is on the side of right and good, and I’m the heretic. I don’t always write my code to be extensible or re-usable. I sometimes write it to be quickly re-edited and patched whenever I need to. Is it full of magic numbers? Sure! But I know just where they are and how to change them. Heck, most are even well documented in their own header file. You could probably figure it out just about as fast. Would my father-in-law be able to tweak the timezone? Nope! But this ain’t his project anyway.

Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more. Don’t be afraid to edit code. Tweak, compile, and re-flash when the situation changes. After all, that’s how you got the code there in the first place.

And although I’m on the wrong end of history, in this case I was right. You see, before daylight savings time could come around again, and I could have made use of that captive portal that I didn’t bother coding up anyway, my son entered first grade. Everything needs to be changed, from the hardware to the software. Will I code up the next version with flexible time regimes? As flexible as I need it to be, but not more.

Inputs Of Interest: ErgoDox Post-Mortem

In the last installment, I told you I was building an open-source, split, ortholinear keyboard called the ErgoDox. I’m doing this because although I totally love my Kinesis Advantage, it has made me want to crack my knuckles and explore the world of split keyboards. Apparently there are several of you who want to do the same, as evidenced by your interest in the I’m Building an ErgoDox! project on IO. Thank you!

Well boys and girls, the dust has settled, the soldering iron has cooled, and the keycaps are in place. The ErgoDox is built and working. Now that it’s all said and done, let me tell you how it went. Spoiler alert: not great. But I got through it, and it keyboards just like it’s supposed to. I’m gonna lay this journey out as it happened, step by step, so you can live vicariously through my experience.

Continue reading “Inputs Of Interest: ErgoDox Post-Mortem”