Five Developer Anti-Patterns

on my mind today, after 20+ years of writing code

1. Premature Optimization. Well known. You made the code more complex and less clear to make something faster, but it didn't need to be faster, and you wasted your own work making something faster that didn't need to be faster. (faster/smaller/other optimization goal)

2. Premature Generalization. Only slightly less well known. Making the system that could be anything, could grow in any direction, has hooks for every eventuality, but those most of those things won't be used and were a waste of time to build and add complexity and may ultimately make it harder to develop in the direction the code actually needs to go.

3. Dependency Bloat. Everything you import is a possible bug and a possible supply chain attack. It slows down builds. When I code review a pull request that adds a library maybe I should code review the entire library added. (A few things get a pass for sufficient reputation and community usage.)

4. Excessive Cleverness. Yeah, you could do it in a perl one-liner, but maybe you should write it plainly, opened up into normal nested loops on several lines to show all the parts clearly.

5. Spooky Action/Magic. If I call thing.foo.bar() is that exactly what happens or does hidden code happen automatically? If thing.foo is type A but can be automatically converted to type B to run .bar() on, that might be bad magic. (Ruby on Rails is the worst at this, C++ does it a bunch, and Rust does it more than it should; Go pushes back hard to the point of being a little tedious about it)

Off Grid Starlink Power Usage

I have a rectangular dish I got early 2022. I have an off grid solar power system running it, so I like to keep track of how much power various components are using.

The Starlink system sits by itself on a smart Victron Energy inverter (a small computer and other things work on a separate DC-DC converter from the battery). The inverter posts status to a serial port about once a second. Across 883129 data points (about 10 days) I gathered data and did some analysis.

The mean AC current supplied was 0.32 Amps. The peak was 0.9 Amps. (The mean AC voltage output was 120.01.)

Here's a histogram of the number of samples at each output current:

0.2 A	88114
0.3 A	556319
0.4 A	215524
0.5 A	19858
0.6 A	2627
0.7 A	560
0.8 A	114
0.9 A	13

I've seen other reports that the Starlink terminal uses about 40 watts and we're in the neighborhood of that. Also the good news is I'm well within the specs of the 250 VA rated inverter I got for this.

I plotted the results but didn't see any pattern to the spikes. Nothing jumped out like "once an hour" or "every morning at 2am". Maybe it has to do with where the satellites are, the weather, or birds flying over head.

I'll keep collecting data but I'm not expecting any updates to this. But yay, now I know.

Yoga for Nerds

I grew up a nerd, which is the opposite of a jock, so embodied athletic things were not part of my identity. I was more reaching for the ideal of brain-in-vat purity. (Did band and ran 5k anyway) At various times yoga has pushed me away (too much woo-woo usually) but now it works for me, here’s how

Local Election Drama Shows Need For Open Source Elections

tl; dr: Election; certification; software oops!; swearing in; lawsuit.

The Oakland, California School Board election of 2022 is still contested. At first it seemed straightforward; the election and certification went by apparently well. Then, December 28, the Alameda County Registrar of Voters posted an oops, "its RCV tally system was not configured properly". In January the initially certified winner, Nick Resnick, was sworn in. Mike Hutchinson should have won by the corrected count, and he's pursuing a court challenge to fix the outcome in his favor.[1]

The specifics of the problem to me sound like a bug in the implementation of the "Instant Runoff Vote" algorithm used in this RCV election. From the AC ROV press release:

It should have been configured to advance ballots to the next ranking immediately when no candidate was selected for a particular round.  This means that if no candidate was selected in the first round on the ballot, then the second-round ranking would count as the first-round ranking, the third-round ranking would count as the second round ranking, and so on.

To me that doesn't sound like a "configuration" issue, but a straight up bug in the implementation of IRV. I can't imagine the behavior described as being the desired 'correct' behavior in any context. The bigger problem is that we don't know what happened because we don't have the source code. I can post my count of the election, but so what? We don't know what's happening in the official count.

I previously posted about how San Francisco elections don't quite reproduce, not with a big enough margin to change any outcomes, but it's still at least a little worrying that the official cast vote record can't seem to reproduce the officially certified counts. Where did those counts come from? What data were they using? What software and settings did they use to count the votes? We don't know. San Francisco is doing good for the world by publishing their full cast vote data, and we should thank them for that, (and Minneapolis, Minnesota, and the State of Alaska, and a few other places intermittently posting RCV data).

We need our elections running Open Source software that can be publicly verified, otherwise we kinda can't have elections be publicly verified. In this case, a hand count of the 26,714 votes is still a manageable inconvenience, but a future state-wide election with millions of votes might not be feasible.