The little things matter

When working on software, I've noticed a tendency in myself and others to overly focus on the MVP. We aim to get the big stuff working as soon as possible, with some vague promise that we'll apply polish later. While this is efficient from a corprorate perspective, I still feel it does a disservice to building quality systems in the long run.

Think about the various systems that you've used. Think about what you like about some of them, and what you don't like about others. Chances are you'll like something rather trivial, when you view it at a distance, and dislike something for, again, a rather trivial reason. These are the little things I'm talking about. Tech debt, warts under the skin, or a messy back office are all problems, but they aren't the problems that often make or break something.

Picking code editors

As a programmer, I'm rather passionate about my text editor. It is the canvas upon which I work, after all. Over the years I've moved between editors a few times. Starting out, I used vim (technically Elvis, as the early 00s didn't see particularly well implemented vim GUIs on Windows). I'd use Notepad++ a few times, but always came back to vim. When I got my first Mac, I used Textmate 2, followed by SublimeText 2, followed by Atom, and now I use VSCode.

Vim is a perfect example of little things mattering. Vim is atrocious when it comes to discoverability. There are no contextual hints, no helpful pop-ups, no type-aheads that guide you. You're tossed in to the deep end, and have to learn piecemeal. But every time you figure something out from the manual, a tutorial, or a coworker, you get a little jolt of endorphins. Vim is excellent at focusing on little things. Textobjects are a perfect example. I'd wager a very large plurality, if not flat majority, of vim users don't use nor care about textobjects. But when you're working, being able to replace the whole word/paragraph/line/region/quote content while your cursor is inside it saves you time, and makes you feel just a little more efficient.

TextMate 2 can be looked at as the beginning of the "editor revolution." Yes, there are very good Mac editors that predate it, such as BBEdit and TextWrangler, but TM2 did so many little things right, that its legacy is felt today. Most modern syntax themes use a format devised by TextMate. The idea of a heavily pluggable editor, while not new (Vim and Emacs have had plugins forever), was popularized by TextMate 2. And TextMate 2 had something else going for it: it was pretty. Working with something that looks nice is a lot better than working with something that's functional, but ugly.

When TextMate 2 got a bit long in the tooth, and some work paradigms shifted (i.e. using a tree view baked into the editor came into vogue), I moved to SublimeText 2. ST2 did a lot of things well, and a lot of those little things were carried over from TextMate 2. But ST2 also introduced its own little things. The keyboard-driven quick command menu is fundamentally no different from Vim's command mode or various Emacs chords, but in practice, the little UI that comes up when you trigger it, the typeahead nature of it, and the implicit discoverability, all tie together to make it a better user interface. Atom and VSCode have also copied this pattern, and it's now emergent in pretty much every technical application out there. Even "creative" tools like Photoshop have implemented similar features.

Atom improved dramatically on how much power third party plugins can have, both over the text, and over various presentational aspects. Things like rich markdown preview, regex railroad graphs, embedded diagrams, and whatnot were the little things atom added that dramatically improved it over sublime text, enough that the performance hit was worth it. VSCode further improved on this by adding performance back while only limiting plugins in certain ways, and by introducing standardized ways to build support for IDE like features, without needing a big heavy IDE.

I also tried Emacs for a bit. I like a lot of the "big things" about emacs: it's modal, it uses lisp for everything, it has features out the wazoo, org mode is hard to beat, etc. I used the Spacemacs distribution, which adds vim like keybindings, Atom/VSCode like command palettes with typeahead discoverability, and some helpful conventions for how everything works. I spent a decent amount of time fiddling with my configs, writing a ton of (very fun) lisp, and just seeing where I ran into limits.

And one of these limits was what made me stop using Emacs. It was an incredibly trivial thing, and most people would say that it's a stupid reason not to use it. But it was a nucleation point for dissatisfaction. That small issue? Smooth scrolling. Emacs is, like vim, generally a terminal oriented program, and as such, scrolling tends to "jump" from line to line. You never have a partial line visible. And that's what I initially noticed. If I was writing a document, there would be a wee bit extra padding at the bottom, where there wasn't enough space to display the next line, but more space than the previous line needed. I tried to ignore it, but it nagged at me. Looking for solutions proved fruitless, the few recommendations some people had didn't work for me. And suddenly, I couldn't not see the issue. Things that were fun before, like editing the configs, took on an air of tedium. I couldn't get it exactly the way I wanted, and so previously where things were just challenges to work around, gleefully, they became chores, annoying issues I needed to fix.

My snowblower

My snow blower isn't tremendously remarkable. It's a recent model Toro two-stage blower, with a 27" scoop. It does its job, well enough, that it's not too annoying to have to blow the driveway after a heavy winter snow. It's reliable, and, provided the snow is dry enough, has never failed me. But it's better than every other kind. It doesn't move snow any better or worse than other brand. Its tires aren't better or worse than any other brand. Its motor isn't easier or harder to start than any other brand. What makes it better is one little thing: the chute controls.

If you've never used a snowblower, you might not know what I'm talking about. A snowblower is a machine, typically gas powered, although there are electric models, that uses a large auger in a scoop to pull snow from in front of it to the middle and back, into a chute. Two stage blowers use a fan (of sorts) to push the snow up and out the chute, with enough force that you can clear a snowbank and blow it into your yard. The chute typically needs to be repositioned a few times during use, so you can aim the jet of snow around obstacles, or as you reorient while clearing a space.

I tend to clear my driveway using a spiral pattern. I aim the chute to the right, and start traveling down my driveway. At the bottom, I turn 180º left, and repeat the process. This creates an ever widening space of cleared snow, pushing the removed snow out and off my driveway. By doing this I never have to reposition the chute, in theory. But in practice, as I get to the outer part of my driveway, I want to aim the chute so as not to spray snow onto my neighbors house. And when I get to a certain stage, it doesn't make sense to continue spiraling, because the other side of the driveway has been completely cleared, so I switch to a more simple back-and-forth method, swapping which side the chute aims at with each reversal. When clearing the area in front of the mailbox, I want to direct the snow around the box, so it doesn't fill up and soak any letters inside when the snow melts. And when doing walks, I typically make one pass down the walk, turn 180º, turn the chute 180º, and walk back. Not too much chute movement, but its consistent when it pops up.

Every blower I've used before has varying degrees of terrible chute controls. Some have fixed angle, which is set via a screw, and can't be changed. That's not really too much of a problem, you just aim the chute down and go about your business. But the direction is the issue. Many have a crank and worm-gear based approach, so every time you want to move the chute 180º, you have to spin a crank far too many times. Do that at the end of a few runs, and you'll start to hate the thing.

Which is where the Toro's approach becomes the distinguishing little thing. Toro uses a control interface that works like a joystick. You grab the stick, and can move it around a hemisphere. Every movement directs the chute in some way, either adjusting the throw angle or the direction. Reversing the chute to throw to the opposite side? Just move the joystick, so it points to the opposite side. Want to throw snow high up in the air to distribute it across your lawn? Pull the stick back. It's so intuitive you don't even think about it, you just do it. It saves maybe 5 minutes a job, nothing significant, but when you're out in the cold and wet, those 5 minutes sure can drag on.

Lutron home automation

The first home automation device I ever purchased was an X10 module and IR remote. I bought it at a neighbors garage sale, for about $5. I was 10 years old. It was extremely cool to ten year old me. I never managed to get any apparatus to connect it to my computer, and after the shine wore off, it went into a drawer with other toys.

I'd followed home automation on and off for years after that. Eventually, in late 2015, while renting, I built up enough of an interest to buy some Z-Wave switches, a USB Z-Wave stick, and got started. Our rental home eventually sprouted automation in all the places that mattered; the bedrooms, hallways, and living room. I never got around to the kitchen or bathrooms.

Z-Wave was good enough, but it had a few problems. First, every software package out there had its flaws. HomeAssistant, at the time, was extremely immature and not very easy to use. OpenHAB had issues with Z-Wave locks. HomeSeer was paid, and felt dated, but "worked." Everything was a compromise, including hardware. Most switches at the time were somewhat limited in what they supported. Most didn't have comprehensive central scene support, many didn't even have proper reporting, and very few had more than a single association. Software at the time basically assumed associations didn't exist, so if you wanted to network a single smart switch to control two loads, you had to create an "automation" in your software of choice, and then hope the server it was on was reliable enough to stay up so you didn't have to think about it.

Furthermore, there was a small variety of Z-Wave devices beyond the standard switches, plug modules, and motion sensors. Want a decent looking remote? There's maybe one, and its got a somewhat modern experience. Its not something that a guest could look at and immediately intuit. Other, closed ecosystems, in this case Lutron, have very stylish remotes available. When my primary load control for my home automation was Z-Wave based, I invested in a Lutron Caseta bridge, a few plug modules, and a hand-full of Pico remotes, because they looked, and worked, better than anything in the Z-Wave system. Z-Wave was still what I put in the wall, the Caseta wall switches at the time were rather "techie" looking, and the better looking Maestro switches weren't an option unless you upgraded to RadioRA2. RA2 select, the Sunnata dimmers, and other modern additions to the Lutron product line, didn't exist at the time.

Aside from looking better, Lutron's plug modules and remotes had a few other things going for them, that weren't possible (at least from my research in 2016) with Z-Wave. You could hold down a button on a Pico remote, and the corresponding loads would change while you were holding it. Release the load, and the lights would stop at the level you released at. Z-Wave required you to work in "steps" and fixed percentages; you'd say set bedroom lights to 15%, and it would undergo a smooth transition to that 15%, but if you weren't sure if you wanted 15% or 20%, you couldn't hold the button down until it "looked right".

When we finally bought a house, I decided that our HA was going to be much more Lutron based than before. Z-Wave had served me quite well, but the little things about how adjusting loads worked, about how the switches were rather ugly (unless you sacrificed features), and how software support was patchwork, had soured me on it. Fundamentally, Z-Wave did everything I wanted, but so did Lutron, and Lutron did it better. I got myself an RA2 inclusive certification, and have slowly been adding lights to each room in the house.

Lutron isn't without its shortcomings. Advanced logic is locked out of the RA2/RA3 product line; you have to buy into a HomeWorks system, which has basically no way to DIY it. The programming software is windows only, and has its own set of odd terms and features. Integrations with third parties, in this case HomeAssistant, work well enough, and let you fake certain logic features that would otherwise be unavailable. But, even in spite of all those things, Lutron scratches the itch of "little things" that Z-Wave, ZigBee, X10, and whatever else never did.

Ok but who really cares?

When I'm talking about the above points, or really anything with similar sentiment, I'll have people express some variant of "Ok, that's cool, but who really cares?" And that is a valid point! If you endlessly focus on the smallest thing, you can be prone to bike-shedding. But if you ignore them completely, you may ship sub-par products. You don't need to dive into a mire of minutiae on every subject. I find periodically stopping, taking a look at what you're doing, and seeing if there's a better way to do it is often worth the small-time detour it takes to implement.

If you have a command line task you have to execute fairly regularly, and are relying on your shell's history to pull it out, why not just copy it into a script, and then just add a few niceties around it? Modern shells have nice tools for argument parsing, so instead of having to edit the command line each time you have to do something slightly different, just encapsulate those in arguments. Future you will thank you for your foresight. Doing this doesn't take much, doesn't add much, but it's a little thing.

If you use a tool every day, you might as well look at the pain points, and try to optimize them away. Someone else may have had the same problem you did, and may have written an extension or tool that solves it. And if not, and you come up with it, someone else may stumble across your solution.

Everyone pays attention to the big things. The features listed on a marketing page, the topics mentioned during keynote speeches. No one ever really considers the tiny little thing, most don't even notice it. But when they're gone, you miss them.