Another Rodeo

1971 Eco fiberglass camper restoration

2020-01-07T00:00:00Z

The more or least restored trailer, ready for camping.

1971 Eco camper restoration

In 2019 I became convinced that we should have a camper. And not just any camper, we should have a fiberglass "egg" camper. Through a highly improbable coincidence, it turned out a friend had one and he was willing to sell it to me for "friend price." And so I lugged this little thing home. The pictures and story here are incomplete and fractured because I'm recreating the restoration story from whatever files I can find, but I'll recreate it as best as I can.

As I found it, it had seen better days. It looked a bit like a baked bean, and smelled a lot like old, rotten beans.

It just *barely* fit in my garage bay. That made the restoration a lot easier. Just go out to the garage and get to work.

As an Amazon Associate I earn from qualifying purchases. In other words, I get commissions for purchases made through links in this post. When you follow a link and buy something, it doesn't cost you anything extra, but I may make buck or two. So thank you! That said, any recommendations I make are my recommendations, based on my experience, and are not paid endorsements. I only point you toward the stuff I use, and if I don't like it, you'll hear about why.

So what is this thing, anyway?

In the '60s a company called Boler pioneered these little fiberglass "egg" campers. Where most campers at the time nailed aluminum into a wooden structure to make the camper (or in the case of Airstream, an aluminum frame) these were different: there was no framework for the body, because the fiberglass is self-supporting. So they're extraordinarily lightweight, easy to tow, and much less likely to break, leak or just fall apart.

Through a complicated series of events I won't get into here, Boler's original fiberglass molds ended up in the hands of a bunch of different manufacturers, including this Eco, which was built in Nebraska in 1971. I'm told the factory later specialized in fiberglass prosthesis when they got out of trailer-building.

Anyways, the original Boler design continues on today under the Scamp name. Pretty amazing longevity, but great design endures. If you're interested, there's a lot of history about them out there.

Here's the original Boler floorplan, still in use in Scamps today (and in my Eco). Photo courtesy of Scamp Trailers.

The teardown

I was lucky it was such a great design and couldn't rot. At least I didn't have to worry much about the body. But everything inside sure could rot. And had.

When I brought it home, my wife would not step foot in it. To her credit, it really was pretty disgusting. There was carpet in it that had seem some terrible things and a smell that could stop traffic.

Underneath the disgusting carpet the original super-70s linoleum was still in place, albeit covered in 50 years of funk. This is the dinette side of the grailer. A few hours after this picture was taken, the cushions and linoleum joined the carpet on the curb-side trash pile.

There are cabinets above the sink/kitchenette area. The doors, light fixtures and backsplash were all in terrible condition.

The sink itself was no better. But it did have lots of extra holes for whatever reason.

The overhead storage and the front and rear was notable mostly for the sheer number of hooks that you were absolutely certain to hit your head on.

The very first thing I did was remove every fibrous surface from inside and put it all in the trash. All the cushions, the drapes, everything. If it was porous, it got yanked out and thrown out. I also found some other things I'd rather forget about, like the ancient camping toilet. Ugh.

Won't be wanting any of that anymore.

Everything that was left was bleached, then gone over with a trisodium phosphate (TSP) cleaning solution, and then painted over with a couple of coats of Killz. There was a lot of mold, a pretty good ant infestation, and a couple of dead rodents.

Too much of it looked like this. No, I don't know what all that was, either. But it smelled as bad as it looked.

By the time this photo was taken I was deep into bleaching the whole interior and hitting it with TSP and then Killz primer .

Eventually, it started to became a nice clean bare white canvas.

The fixtures and shelving, like the body, are all fiberglass. I filled a lot of holes in them. Then I filled a lot more.

I didn't have a lot of faith in this 50-year-old propane stove, nor did I really want to be cooking eight inches away from where I'd be sleeping.

Here the kitchen unit is nearly completely stripped down, with the original sink and stove gone. You can also see where I filled in some more holes on the front. I didn't need to fill the ones on top because I was building a new countertop.

Troubleshooting power issues

Having a usable electrical system in the trailer was quite a journey. When I first bought the trailer, I plugged it into 110V household power and got... nothing. As I investigated more, I learned two things:

The original power center for it had long ago been gutted, with the original transformer removed and a nonsensical bit of splicing put in its place. Electricity was going places, but not the places you'd want it to go, and definitely not in the right wires.
That length of household wiring laying out on the trailer tongue, going nowhere? It was hooked up directly to the 110V shore power. So it's probably good that I didn't touch it.

Seriously, the more I dug in, the more it was clear the existing wiring was just flat dangerous. Major work was going to be needed.

The dangerous remnants of the original power center.

So after some research I placed an order for a Progressive Dynamics 4145 Power Center. It's compact, full-featured and packs more than enough potential power for my little trailer.

Before I could do anything to install the new power center I had to drill out the rivets holding the old power center in place, then significantly enlarge the height of the hole for the new power center. A few minutes with a drill to mark the corners and a jigsaw to cut through the fiberglass and that was done. Note: Be sure your eyes, skin and mouth are well-covered. Fiberglass is nasty stuff.

You can see my marker lines where I had to enlarge the hole for it to fit.

But my newly cut hole was about 1/8" too wide because of the width of the old power center. So I had to turn right around and put some trim around the new hole to keep my new height while narrowing the opening a smidge.

Trimmed and caulked. You can see the red fiberglass putty filling some more holes too.

With the hole trimmed out and painted, I still had to figure out how to wire it up, which was pretty tricky and figuring out a good ground on a fiberglass trailer takes some head scratching. The Progressive Dynamics instructions were a little inscrutable, too, but with a little thought and a lot of googling, it went in.

The new power center installed (shown without its cover in this pic).

On the 110 (household) voltage side, I've got one breaker dedicated to feeding the 12v converter, one dedicated solely to the air conditioner, one dedicated to the refrigerator, and one dedicated to a 110v outlet on the front of the kitchenette cabinet. I could have put more on the circuits, but why? I don't need to, and this way there's less chance of a tripped breaker.

On the 12v side, the 4135 offers more circuits than I've yet found a use for, but the first thing I wanted to do was get some light. I found these super-low profile remote control LED puck lights on Amazon and went ahead and ordered them. It'd be nice not doing everything by shop light. I the wall-wart off the puck lights, mounted two in the front, two in the rear, and two over the kitchenette, then wired them up to the 12v supply. Success!

I was pretty proud when I wired it all up and it worked with no extra smoke the first time I flipped the switch.

And now that there's power, let there by light. I got a great deal on a set of low-profile, dimmable remote control LED puck lights dirt cheap on Amazon Prime day and hard-wired them in. There are two at each end and two over the kitchenette, all controlled from a single remote. Six lights is plenty in a 60 sq ft trailer.

Once it was the inside was more-or-less safe for humans to be in there, I hitched it up to take to a local trailer shop for inspection. I needed them to tell me that the frame was solid and straight, and remove this weird rack thing that had been added in the rear.

The strange rear rack in question. Inside you can see the freshly-Killzed interior.

With the rack gone, the bumper painted and the body halfway clean, it started to turn a bit of a corner.

The existing paint was so bad, a Rustoleum Roller job in the driveway was actually a step forward. You can get surprisingly good results with a rustoluem roller job. Seriously.

About half-way through painting it was looking pretty good. I needed more coverage, but not bad. You can also see the vent holes on the front for the AC. Those would be important later.

I painted the original wheels with Rustoleum white, too, and fitted some new baby moon hubcaps. You can also see some fiberglass damage from a long-ago blowout. Someday, when I get a pro paint job, I'll have that repaired. I did put new tires and bearings in, though.

All the exterior lights were upgraded to modern LED versions. Yes, that's another tiny bit of fiberglass damage by the bumper. It's 50 years old, it's picked up some scrapes.

I also started test-fitting a new countertop I'd make from birch plywood.

And the new flooring went it. Vinyl planks were easy to work with, worked well with the campers irregular edges and lines, and are waterproof and wear well. Pretty much perfect for this usage.

A prior owner had cut this hole for the AC, which is pretty far from ideal as far as cooling efficiency goes, but since the hole was already there I put a fresh AC in it. I spent a lot of time insulating the hot side of the AC from the cold side and figuring out how to vent the hot side. Eventually I put in three temperature-activated 4-inch fans venting to the outside. When the AC is on, they sense the heat and turn on, pushing the hot air out of the trailer.

A lot of things were being test-fit here, particularly the new countertop, a new bar-sized faucet and the backsplash. You can also see the new electrical outlet (complete with ground fault protection and two USB ports) and over to the right, the new sink waiting to go in. Both the sink and faucet were bar-sized because the scale worked better for the little camper. We decided to skip the propane stove and either cook outside or with a hotplate.

The kitchenette with it all actually in place.

I was really proud of this drawer I built from scratch, including all the mounting points. The original drawer slid out from the bottom of the stove, and both it and the stove were unsalvageable. So I had to get creative.

These fiberglass campers need supports from the floor up to the ceiling or else the ceiling can sag and they get oval-shaped. In mine, someone had taken the supports out so I had to use a floor jack to lift the ceiling and install new supports.

The supports themselves are just bits of poplar. Some Ikea pegboard helps keep things square while providing some extra utility. This is the sort of usable-yet-attractive detail I just love.

Before I tossed the old cushions I had the good sense to make patterns from them on heavy brown paper. Those were really handy later, when I needed to cut new cushions. The new cushions were cut from a 5-inch memory foam mattress from Amazon, and the houselhold electric carving knife, which is a pretty good solution for cutting foam.

I don't have an industrial sewing machine or any real upholstery skills, so I figured it was smart to farm out the actual upholstery work. We had the cushions covered in a nice high-quality marine vinyl in a sort of two-tone gray/beige color. We deliberately kept the colors very neutral and cold. The camper is so small that even a single pillow introduces a lot of color. I made the dinette table, too. Then later I made another one, 'cause I didn't like this one.

I had the upholstery done in the late in 2019. By early 2020, the basic renovation of the camper was done and it was a pretty nice place to be.

Of course just a few months later, as the weather just started to warm up, Covid hit, so there wasn't a whole lot of camping going on.

I turned my attention to modernizing the electronics and entertainment, and making a "smart camper" out of it. That had mixed results but was a lot of fun.

Why did I do it?

Well, I thought I wanted a camper, and I liked the scale of the renovation project

What did I learn?

I don't like camping all that much.

Where is it?

Currently, in my garage.

The bedraggled Raleigh

2020-08-23T00:00:00Z

I've had an urge to take experience a classic British three-speed for awhile now. The laid-back geometry, relaxed, upright ride and smooth internally-geared hubs just speak to me.

In the time of COVID, even ragged projects seem to be fetching an awful lot of money, and since I already had too many projects going anyway, I figured that would have to just remain a daydream for awhile.

The Raleigh Sports, as found.

And then this Raleigh turned up, literally asking to be picked up from the curb. Who could resist a free Raleigh Sports? So, after taking just enough time to be sure it was mostly all there, I drug it home.

And I quickly discovered there were reasons it was free. It was really in pretty rough shape. I expected the tires to be flat, and for it to be grimy. Honestly for free, I didn't expect much, but figured even if it was a total bust I could just tuck the Sturmey-Archer three-speed hub away for some future project.

Even so, I really didn't know what I was getting myself into.

The battered chainguard appeared to be held on mostly with grime, and that three-speed cable may be past its prime. The decal style places it somewhere in the mid-70s, probably.

The rear fender is similarly battered and rusty.

Lots of surface rust and grime.

So filthy. So very, very filthy.

I think I should be seeing a spoke here. Amazingly, the Raleigh steel rim was still surprisingly true.

The original Raleigh pedals should clean up well. They were really built to last.

All the smart parts are put in bins and tagged as needed to keep track of them. Yes, there are a lot of loose bearings in a Raleigh headset.

Two days with a heavy-duty clamp and penetrating oil, and still, one of the cotter pins would not budge.

Eventually I had to resort to drilling it out. Which was as terrible as you might imagine.

When I finally got the bottom bracket apart, I found the remains of a whole colony of approximately ball-bearing-sized insects in there.

Once it was in the shop getting disassembled, I got to learn a few quirks of old Raleighs:

They're ridiculously overbuilt. Even though the '70s versions (like this one) cut a lot more corners than the legendarily well-made '50s versions, it was still clearly a bicycle that was built to last. Which means even parts that seem way too far gone to save tend to clean up well, most times.
None of your wrenches will fit. Raleigh used their own standards and if either a metric or standard wrench fits, it's down to luck and coincidence, so you best have a collection of good adjustable wrenches. I like this Channel-Lock, which doubles as a cone nut wrench.
There are a ridiculous number of ball bearings in old Raleighs, and they're all loose. Be sure you're ready to catch them all when you open up the headset, bottom bracket, or basically anything else.

Reassembly

The Raleigh Sports frame, polished up.

The Raleigh had clearly been left outside, unloved, for a long time. There was a thick layer of grime and tree sap that had sun-baked deep into the paint. Cleaning it was a multistep process:

Household multi-purpose cleaner and a blue non-scratch scrubbing pad to get the surface grime off.
Turtle Wax Heavy Duty Rubbing Compound to try to cut the paint back to the original Lemon Yellow as much as possible. This was only somewhat successful.
Turtle Wax polishing compound to bring some shine back to the paint.

In the end, the paint is still pretty chipped and scraped, but it's yellow again, and shiny, and the patina does have appeal.

The fenders went through the same process, although they had an extra step of bending and hammering the metal back into some semblance of shape. I am not a metalworker by any means, but anyone with a little care can do some basic things to make the metal at least a bit more presentable. One of these days I'll get myself a proper set of metalworking hammers and dollies.

For the chrome parts, I sprayed a penetrating oil and scrubbed with fine steel wool. That's always worked well for me. Once the grime and surface rust was gone, Mother's metal polish brought back the shine.

The 'heron' chainring was in pretty rough shape.

But it cleaned up surprisingly well.

The brakes, as found.

And after cleaning, ready for reassembly.

The brakes back on the bike, along with the revived front fender.

Here you can see the in-process front fender alongside the as-found rear fender and chainguard. The chainguard may be a lost cause.

The rear wheel - spoke replacement, tensioning and trueing.

The rear wheel was a special challenge, since it was missing a spoke. After measuring carefully I ordered heavy-duty spokes and a spoke wrench. Neither is anything fancy, but they were more than adequate for the task at hand.

I knew most of the spokes were under-tensioned, but had to do some research on how to easily check the tension. I was pretty happy when I learned you can "tune" spokes to notes on the scale. With that knowledge in hand, I grabbed a Snark tuner and an Irwin Quick Grip,and went to town. The Snark was clipped it to the seatstay to easily see the note the spoke was ringing out, while the Quick Grip accurately held the newly polished brake calipers in position.

Trueing the wheel, home-style.

I can't claim the end results are pro-level, but I can't complain, either. The rim stays off the calipers and is pretty darn close to straight. Not bad for a first timer. It doesn't hurt that those heavy steel Raleigh wheels are pretty forgiving.

Final steps

With the wheel straightened out, the rest of the rebuild was largely replacing the wear-item parts on it, including a new KMC single-speed chain, some faux-leather grips, new yellow brake and shifter cables and inexpensive brake pads.

I also had to buy new cotter pins to replace the ones I destroyed in the removal process.

And with that, it was done.

The finished product.

Truth be told, the frame is way too big for me and I'll probably end up selling it, letting it go to a new home and fund the next project. But for now, I'm enjoying it as it is. I call it "Lemon".

August 2020: Goodbye, Raleigh

The completed Raleigh .

I really enjoyed rebuilding the Raleigh Sports and learning so much more of the lore of these fascinating bikes and their indestructible three-speed hubs (thank you Sheldon Brown!) I really liked riding it around, too. The upright position, the smoothness of the internal gearing, the character of it, all that appealed. I found it thoroughly charming and enjoyed almost every minute of the restoration (except those cotter pins), especially since this particular example was so close to the brink before I brought it back.

But really, it's quite a bit too big for me, and I can't keep them all. So on the market it went. And as it turned out it went to a very nice young lady who's already an avid rider, but wanted something fun and funky for around town. The lemon yellow Raleigh seems to fill the bill perfectly, so I think it went to a good home. I hope it's good to her for a long time. Raleigh sure built them to last.

Making a smart vintage camper

2021-05-07T00:00:00Z

In early 2020, with my restoration of a 1971 fiberglass "egg" camper well underway I started thinking about how it could be fun to bring some modern technology to it. I mean, if you could bring modern automation, monitoring and entertainment to a 50-year-old travel trailer, how cool is that?

All of the code for this project is in the pi-smarter-camper repo.

To get started, I looked at a Raspberry Pi I had recently picked up (back when you could still do that), it seemed like it would make the perfect base. It's small, affordable, works well on low voltage and is basically built for the sort of experimenting I'd be doing.

So I took a good guess at what I'd want and started putting some parts together in a a decent-sized water-resistant enclosure. It was bigger than I needed, but would still tuck neatly into the bottom of the closet in the trailer, by the wheel well.

Inside the box I mounted a Pi 4 using lightweight (and corrosion resistant) nylon stand-offs. I could probably have used a cheaper Pi but I thought the 4 would provide the best media server capabilities, and best handle multi-tasking other things I want to do.

I put in a 250GB SSD drive, chosen because it was reasonably cheap, appeared to be rugged and supported fast USB 3.1. I needed a drive to hold all the media files. I drilled out the faux bolts in the corners and then mounted the actual drive to the enclosure lid using stainless steel machine screws and acorn nuts.

A simple 12V-5V stepdown converter took the camper's 12V system power down to something Pi-Friendly. I also added a Power button with LED to safely power the Pi up and down. The button is recessed so it won't get toggled accidentally as the trailer jostles around, and it incorporates an LED so I can see if the PI is on or not. Pretty spiffy.

I also ordered a 15.6" touchscreen monitor. It checked all the boxes for my purposes:

Touchscreen, so it can act as a control center
Large enough and high enough resolution (1920x1080) to comfortably watch movies while in bed.
Will fit on the closet door
Single USB-C cord for power and data

Wiring a Pi power switch

Wiring up a Pi power switch seems like it should be the simplest thing imaginable. It is not. That said, it's not that hard once you sort through a gazillion how-to guides to find the one that makes sense. There are nice, helpful scripts in the the Pi Power Button repo and related instructions, which make the scripting part pretty straightforward.

The key is to use a momentary switch with a resistor built in, so you're protecting the Pi. I used this power button with LED and have been happy with it.

Note when you're following the instructions, the files don't have to be written -- they're in the repo. Just use cp to move them where you need them and be sure to chmod them to set the permissions. A simple tutorial took care of the LED portion of the switch.

One catch: because there's a power switch and an LED, you have to think through the GPIO pins a little more. I used 5 and 6 for the Power button, as outlined in the instructions, then used 8 and 14 for the LED.

Installing a motion sensing camera

I wanted to have a motion sensing camera by the front door of the camper to provide a layer of security when we're not there. I'd already prototyped one with a Pi Zero -- that was my first Pi project -- so it seemed like a good place to start here, too.

I needed to drill two holes in the cabinet side wall, one each for the PIR sensor and one for the camera. This hurt a bit, since I had filled dozens of holes in the fiberglass since I got the trailer, but I figured I'd filled so many holes, what's a couple more if I needed to fill them later. A step drill bit really helps for these sorts of things, and it made short order of making a couple of accurately sized holes.

My accurately placed and sized holes.

Inside the closet, I continued to ignore the long-unpainted fiberglass (you can't see it anyway) and used a bit of butyl tape to hold the PIR sensor in place. Butyl tape is amazing stuff. If you have a travel trailer, you really should have some on hand.

Butyl tape to hold the PIR sensor in place.

To get from the camera and sensor at the top of closet to the Pi, which lives in a box at the bottom, I had to pick up a two-meter Pi camera ribbon cable and splice in a lot of extra wire to run from the PIR sensor to the GPIO pins. I used some white duct tape to keep it held safely in an existing channel at the side of the door.

I color-matched the wires and put heat-shrink on the splices. The exrtra-long ribbon cable for the camera is also visible.

Then I used a Dremel cut-off wheel to cut a groove in my project box and fed the wires in, with more butyl tape to keep dust and moisture out.

Almost all wired up.

From there, it was just a matter of hooking up the ribbon cable and the PIR. The ribbon cable is easy and for the PIR there are only three pins: One of them goes to a 5v pin on the GPIO, one goes to ground, and the center output pin. In my case, the code expects it to be Pin 7.

Testing the motion sensor hardware

With both the camera and the PIR motion sensor wired in, I wanted to test it before going further.

When I SSH into the Pi, I should have been able to run raspistill -o testshot.jpg from the command line. But since this was a fresh Pi, I got a Camera is not enabled in this build error. I needed to sudo raspi-config and turn it on.

But after that, I still saw Camera is not detected. Time to go double-check the wiring. Sure enough, I inserted the ribbon cable backwards, like I always do. Rasperry Pi tries to make it idiot-proof but apparently I am a special kind of idiot.

After double-checking all connections raspistill -o testshot.jpg was running correctly. Now it's time to write some software.

The motion sensor code

All of the code is in the pi-smarter-camper repo. Inside the Flask app.py file there's a fair bit of setup going on.

In index we're creating a lot of variables that are, by default, nothing. But if they get set later we'll be able to show the status.

The real meat of it is happening down in camera_action, which lets us toggle the camera off and on.

In particular, if we're turning the camera and motion detection on, we're starting it in a thread in the background, so the webapp can go ahead and continue to do its thing.

When we start the camera, we're calling start_motion_detection from monitoring/motion_sensing.py. This is made much simpler thanks to the gpiozero library.

Basically, the start_motion_detection function initializes things, starting up the motion detection and configuring the camera. Then, when some movement is detected it uses a lambda to call take_photo and actually store a photo locally.

Back in the app.py actions function, the second half just handles clean shutdown. If we turn the camera off, we want to be sure we cleanup on the Pi and leave everything as tidy as possible.

Either way, we redirect back to index, now with those variables populated so we can show what we just did. Now I needed a way to show the camera status. A control center, if you will.

Setting up a local web server

The goal here is to be able to monitor the status of things from anywhere, anytime. The easiest way I know to make that happen is with a web server and app.

Normally, Django is my go-to framework for web app work, but in this case I decided to use Flask for a few reasons:

It's really lightweight, which makes sense with the modest demands of the app and the modest resources of the Pi.
I hadn't used it before, so there was a nice learning opportunity.

Keep #2 in mind, though, when you look at my terrible Flask code.

There are quite a few tutorials on how to set up Flask on a Pi, but it's pretty straightforward.

First, make sure everything is updated and upgraded, and install Flask:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install python-pip python-flask
sudo pip install flask

Now, if you were starting from scratch, at this point you'd want to follow a Flask tutorial. But since I have an existing Github repository I can use that will save me a ton of time.

First I navigate to where I want the code: cd /var

I want the code to be in /var/www but the www folder doesn't exist by default. That works well, though, as it gives me a clean place to clone my repository and create the www directory all at once with sudo git clone https://github.com/tBaxter/pi-smart-camper.git www

You have to run that as sudo to be able to create the www folder you're cloning into, but once you've done that, you can transfer ownership to the regular pi user with sudo chown -R -f pi /var/www/

If you cd www to go into your new www directory, and then use ls you should see cellular_modem, LICENSE, monitoring, README.md and webapp just like you would if you visited the repo.

From there, you can move into the webapp directory (cd webapp) and start up your Flask app with python3 app.py. If everything is working correctly, you should see something like:

 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: Do not use the development server in a production environment.
   Use a production WSGI server instead.
 * Debug mode: on
 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

From there, go to your browser and substitute the IP address for your Pi (the one you SSH'ed into) for 0.0.0.0 and you should see your new site, running on your Pi web server.

If this was a real server on the open web you'd want to use Gunicorn or something, but since traffic is limited to just me on a local machine it's fine.

Adding the touchscreen

For this project, my first thought for a screen was to use an old first-generation iPad I had laying around. Cost was zero, since I already had the iPad (and a first-generation iPad has nearly no value anymore). And I did manage to connect it up to the Pi and show the screen, which felt like a win, but still, it wasn't a great solution.

It had to connect to the Pi over the network via VNC. With it being a very old iPad, that made it painfully slow.
It was also too small to comfortably watch anything on from any distance.
Since it was connecting over a network it required a network I might not have when I was camping.
It wasn't really interfacing with the Pi. It was still running IOS, so my touchscreen abilities were kind of limited.
On top of all that, mounting it in the door was going to tax my meager woodworking skills.

So with that experiment set aside, I got thinking about the touchscreen I really wanted.

Bigger, but not too big. I need it to be small enough to mount on the closet door, but easily viewable from the bed.
Standard VESA mounts for simple installation.
Powered by 12v or less. I'm not running 110v line just for the monitor.
Very thin and lightweight. Since it's mounted on the closet door, the closer to a flush mount the better.
Simple, direct interface with the Pi.

After digging around a bit I landed on this 15.6" USB-powered touchscreen. Connecting it to the Pi was pretty straightforward and the monitor was mostly plug-and-play.

Testing the touchscreen monitor.

There was one wrinkle: while the monitor is USB-powered and promised to support both touch and video over a single cable, I learned the Raspberry Pi 4 does not support video over USB. Which means I'd need to use a separate HDMI cable. My closet door mounting got a bit more complicated. And ugly.

Worse yet, in the interests of making a very thin monitor, all the plugs come out the side. Having two cords poking out of the side of this thing is not the look I'm going for. To mitigate this I bought a right-angle HDMI cord and a low-profile USB-C cord.

As for actually mounting the monitor, that part was pretty simple. I found a VESA mount template online and taped it to the door to figure out where to drill.

VESA mount template.

It's hard finding anything level or square in one of these old trailers and it was tricky accounting for where the hole for the cords needed to be. If I was doing it again I'd figure out how to put the template on a monitor-sized piece of paper, so I could get a better sense of the overall positioning of things, rather than just the mount points.

For the actual mounting I used stainless steel M4 screws with integrated washers. I make a point of using stainless as much as possible in the trailer.

Creating a dashboard

With the monitor now in place a lot of things are starting to come together, and it was time to put them all in a dashboard control center for the trailer. I'm going to skip most of the gory details of the code -- it's all available on Github -- and instead just talk about what it does.

The first trick to the dashboard is to turn the Pi's Chromium Browser into a full-screen kiosk, which lets us build a web page that looks and acts like a full-screen experience.

From there, we'll use the Flask web app we set up earlier to talk to the Pi's hardware and to serve the "web page" that forms the basis of our dashboard.

The dashboard

Weather

The weather module first geolocates the trailer, so it automatically knows where to get the weather for. Then it uses OpenWeather to get the local weather for that area. I need to add in weather alerts still, but this works pretty well.

Plex

The Plex module, so far, is the trickiest. It's easy enough to get Plex basic info from the Plex API, but harder to get images, and I'm still working through how to best play a video from there. Even so, it alreaady can show what you were last watching and unwatched movies. I'm still working on this one.

Camera

A nice interface to turn the motion-sensing camera on and off, and to report on its status.

Wifi Status

Shows the current Wifi network and it's strength. I've written the code to show nearby networks, too, but I'm not displaying that part yet. This was planned to be the stub for building out more robust Wifi & virtual private network functionality in order to provide safer, stronger wifi for the trailer.

Time/date/messages

Doesn't do a whole lot yet other than show the local date and time. But it's a useful start.

I've got a lot of work to do on all these modules still, but it's not a bad start for a weekend's worth of work! If you have questions, comments, suggestions or whatever, file an issue on Github.

Trimming the touchscreen

With the monitor VESA-mounted to the door, it was fucntional, but I needed to do something about the ugly cords coming out of the side. Looking at the scrap wood pile, I had a revelation. I saw some left-over L-shaped wood outer corner trim that could be cut down to the screen depth and work.

After carefully measuring and cutting, I glued it together with spare wood providing some extra spacing and strength.

Clamping and gluing the frame.

I drilled a hole in the lower corner for a piece of dowel that allowed me to still press the on/off button. Then I painted it white and screwed it in place from the back.

The completed touchscreen frame.

Setting up audio

This whole project had more than it's share of trials, setbacks, false starts and dead ends. If this sort of thing was easy, more people would have done it already. Getting usable audio in the trailer was definitely one of the big hurdles.

I mean, I had a wonderful touchscreen and a Pi running Plex to show movies, and a new problem: I couldn't hear it. The meager speakers in the monitor were mostly covered by the frame around it, and it didn't matter because the Pi couldn't really push enough volume anyway.

Figuring I didn't need audiophile quality just to watch a movie at bedtime or if it's raining, but I did want to put a premium on low-weight, low-cost, low-power solutions, I ordered a Kinter MA170 amp from eBay and some nice little marine speakders.

I committed to doing it and cut holes for the speaker in the new closet door I had just made a couple of months earlier. Wired it all up and... it sounded horrible. Just horrible. A whiney, popping mess. All noise, no audio to speak of.

So I spent money on noise suppressor clips that helped, but not much.

And I bought a HifiBerry which, honestly, seems to solve a different problem. If I'd bought the version with a built-in amp it might have been just the ticket, but I'm unlikely to find out now. This was also a particularly painful dead-end because I spent a long time unwinding the audio settings it needed changed, and I'm still not sure I've got that completely sorted out.

Then I bought a noise isolator which also helped, but not enough.

I mucked around with the power feed, with all sorts of settings (both in hardware and with software) and generally tried everything until finally I figured that everything was playing nicely, albeit with low volume, except the amp. So I broke down and bought another amp.

And this turned out to be a nice little amp for the purpose. The noise problem was gone immediately, it's plenty loud for the trailer and the sound quality is pretty good, even through the diminutive speakers. It turns out the original Kintner amp was just trash, which is why I won't link to it. The new amp works great, though. I'm happy.

Addendum: Setting up the Pi from scratch (as of May 2021)

After using the camper through 2020 -- and utterly failing to document any of it -- I had some ideas on how I could do it better this year. In particular, I found that the thing I used the Pi for most (movies) wasn't working well. I was getting a lot of buffering and audio issues that were unpredictable and frustrating. Sometimes it worked fine. Others, not so much.

So I figured I'd start from the ground up with an OS optimized for media playback. LibreElec, here we come! Why LibreElec? Because it's lightweight, built for media, and as I'm writing this OSMC still doesn't want to play nice with the Pi 4.

So with that said, on with the setup (and a lot of this will look very much like last year's guide).

There are a million and two ways to set up a Pi, but here are the steps I think need to be done every time to set up a Pi from scratch to work well as a Smart Camper media and information hub (recorded here for my own future reference as much as anything).

These steps may also be useful for other Pis acting as similar hubs, such as Magic Mirrors or car-puters.

First, get an OS on the Pi

Use Raspberry Pi Imager to install LibreElec on a good-quality, 32GB SD card. LibreElec is lightweight and optimized for media playback, and we think it will better suit how we use the Pi when we're camping.
Put the new card in the Pi and boot up. Assuming it starts OK, go through the first-run setup steps.
Set a good password.
Be sure to enable SSH
And set a static IP. You'll be glad you did and aren't chasing ever-changing IP addresses set by your router. Note that your ISP and router may require additional work to make this happen.

Install Plex

Ensure the external drive containing the media library is mounted and will mount automatically.
Follow the steps to prep for Plex server installation:sudo apt-get install apt-transport-https curl https://downloads.plex.tv/plex-keys/PlexSign.key | sudo apt-key add - echo deb https://downloads.plex.tv/repo/deb public main | sudo tee /etc/apt/sources.list.d/plexmediaserver.list deb https://downloads.plex.tv/repo/deb public main
Update packages: sudo apt-get update.
Now get the Plex server: sudo apt-get install plexmediaserver
And upgrade: sudo apt-get upgrade. In the past I've cleaned up some unneeded packages, but honestly, it's probably not worth it. They're not hurting anything, really.

Pi Configuration and further installations

Reset the resolution to 1440x900 (at 1920 it's too fine for fat fingers)
Enable 1-wire interfacing, either through the raspi-config "interfacing" option or by manually editing the config.
Install xscreensaver. It's by far the easiest way to control when the Pi and display go to sleep.

Code setup

Pull my smarter camper code from the repo.
Make sure it's on pythonpath: export PYTHONPATH="${PYTHONPATH}:$HOME/var/www"
And just to be sure, put it in ~/.bashrc too.
Pip install dependencies from the repo's requirements file: pip3 install -r REQUIREMENTS.txt
Set environment variables for services we're using. See settings.py for details.
Follow the instructions above to re-install the web server and monitoring page

Peugeot mixte restoration

2021-07-23T00:00:00Z

For awhile now I've been on the hunt for a nice step-through framed bike. My criteria weren't that tough: be pretty, and not terrible. Apparently in the world of step-through frames that seems to be a tall order.

The fact is step-through frames -- even mixtes -- still have way too much of a "girl bike" stigma, and cycling in general has a tendency to treat women (and "girl bikes") as second-class members of the community. You see it all the time: some guy is out front with the latest carbon-fiber Terminator 6000 SEX 40-speed wonder while his girlfriend/spouse lags behind on a 500-pound cruiser, struggling to keep pace, 'cause he's much more serious a cyclist.

Hang on, it's hard to type with my eyes rolling so far into the back of my head.

Anyways, back to the subject at hand: the difficulty in finding a decent step-through frame. I had been looking awhile, but nothing quite worked.

I narrowly missed a pair of nice Bianchis, much to my chagrin. I had an eye on two different Raleighs, but neither quite spoke to me. And I suspect both may have been real heavyweights -- not what I was after. I spotted a nice Miyata and a Univega, but both weren't really priced like project bikes (although the Univega should have been).

Finally, on a whim I inquired about this forlorn Peugeot that had been listed on the local marketplace a full year ago. Astoundingly, it was still available, and could be mine for couch-cushion money. So I grabbed it.

The Peugeot, as found on the local marketplace site., immediately after transport to my basement. The blue tape and plastic bag on the rear wheel is holding parts of the rear derailleur.

To be honest, it's not a great Peugeot. It's an OK Peugeot. I thought it was pretty and nice enough. After some research (and discovering the paper tag still intact on the bottom bracket) I learned this particular Peugeot is something of a rare bird (or lion, as the case may be): it's a circa 1982 PH19, as seen on this catalog page and this ad.

From those artifacts I gathered the PH19 was the mixte variant of the PH10. While the PH10 lasted a few years, I can't find any reference to the PH19 mixte variant after 1982. My guess is that Peugeot had too many mixtes in the mix and the PH19 was squeezed out.

The PH10 and PH19 are a bit unusual for the era, too. Where their contemporaries would have had lugged frames, these Peugeots were lugless and internally brazed. Peugeot made a bit of a fuss about it at the time, claiming a step forward, but I could also see where it was simply a cost-cutting measure. Hard to say nearly 40 years later.

The carbolite sticker tells you a lot about this ex-California bike: This was a high-tensile steel bike, sitting at the upper part of the lower end of the Peugeot line-up. The frame weighs in at 7 pounds even. so it's no lightweight, but the French could work magic with stovepipe frames.

One reason it was so cheap: the chain was so rusty the Simplex derailleur had a broken jockey pulley after someone had attempted to force it to move. Luckily the prior owner had kept the jockey pulley remnants in a ziploc bag helpfully taped to the rear wheel.

The hubs are Maillard, laced to pretty Rigida alloy 27" rims. Not terrible stuff, if I can get it to clean up. If not, it will end up with a 700c conversion, but I would rather keep the original French parts.

There's a pretty nice Stronglight crankset, with a functional plastic chainguard. A Peugeot-branded Simplex derailleur handles shifting. It should clean up OK. The very rusty chain, however, is a goner.

This corrosion around the BB isn't nearly as bad as it looks here. It's really just surface rust and should be easily dealt with.

A good look at the lugless construction and clever Peugeot cable routing.

The original celophane bar tape. Almost everything in this photo will be dustbinned.

November 2020: Paint

I knew when I bought the Peugeot it had some rust. I underestimated the extent of it. I should know better. I've made this mistake before. I'll probably make it again.

Nevertheless, as I cleaned and scrubbed the bike I was clearly losing more and more of the original metallic blue paint until eventually I was clearly going to have to spray some paint.

Rust on the Peugeot. Bad rust.

I hoped to do a partial respray, but matching the light blue metallic proved difficult. Hobby stores couldn't help, and eventually I turned to pricey automotive paint. A local auto paint supply store custom mixed it for me, taking a color analysis of the fork I took in. Auto paint is high quality stuff, but the paint cost me three times what I paid for the bike. And they warned me it still might not be an exact match. It's tough color matching metallics. Any number of factors will throw it off, including temperature, humidity, and my own paint technique.

But I had to try, and I dutifully taped off all the stickers and pinstriping and otherwise prepped the frame for spot painting.

I taped off everything I wanted to keep. If I was doing it again I'd have taped more.

I used a high-build auto primer.

And put the paint on carefully, with very light coats as recommended.

and... nope. Color match fail.

It didn't work. No matter how I buffed and color sanded, there was a clear difference between the new and old paint and it was not going to feather in smoothly.

Sigh.

I was going to have to do a full respray. Which meant replacing all the graphics. I was convinced I'd never find the correct stickers and would have to bodge something together to make the Peugeot together.

Luckily I found the absolutely correct set of decals for this obscure Peugeot. While I had to wait for them to come all the way from the UK, they were beautifully done, and I can happily recommend bicyclestickers.co.uk for any sticker needs.

Measuring and prepping for paint. Again.

Before I sprayed (again) I sanded everything back even more than I did the first time, and carefully measured the position of the existing decals, with lots of pictures.

I really wanted to put it back together looking as close to original as possible, and once I had sanded and painted I wouldn't be able to see where they went. So I figured I'd better get it right before I went any further.

Once prepped, it went out again for priming and painting. After letting the paint dry and harden a few days, I polished it up with Turtle Wax polishing compound to bring out the shine.

Painted and polished, and it looked beautiful.

And that worked. The original rust damage was invisible, and you could never tell the paint is a slightly different shade than the original. While I'm no professional painter, I'm very happy with how it came out.

December 2021: Rebuilding and enjoying the Peugeot

As I waited on the new decals to make their way across the pond from bicyclestickers.co.uk, I started work on all the components.

I could tell the bike had been truly loved once. That had been awhile ago, though, and things were looking rough. It took a lot of time, effort and polishing compound.

It's not perfect by any stretch, but it has a nice blend of shiny new and vintage patina, and it positively oozes Gallic charm. It's the kind of bike that makes you want to buy more just like it, even though you clearly already have one and don't need more.

But that's the finished product. It took a lot to get there, as you can see in the before-and-after photos.

Let's start with the rust. As noted previously, the rust on the frame wasn't deep, but it was extensive. Worse yet, the more I stripped back, the more rust I uncovered.

The rust that launched the respray.

If the bike had rusted from the inside-out then the frame would be junk. I think the California salt air attacked the paint, but not deeply.

In the end, the automotive paint was expensive and worth it. The frame finished up very well, and the reproduction decals completed the look beautifully -- so much so that I picked white accents, including brake lines, to complement the white Peugeot logos.

The PH19 and the closely related (and more common) PH10 were built from Peugeot's proprietary Carbolite 103 high-tensile steel. That should be a recipe for real pig of a bike, but the PH19 rides much lighter and feels lighter than it actually is. Normally I would be a hard pass on most high-tensile steel bikes. I'm glad I gave it a chance.

Carbolite 103 tubing

The permit stickers tell us that at some point, long ago, this was a California bike before it found its way to the midwest and began a long period of neglect.

The bottom bracket also showed a good bit of corrosion, but it was all surface rust, with no pits in the steel, and inside the bottom bracket wasn't rusty. It cleaned up well, as did the original Stronglight cranks. I added a new Greenfield kick stand since it's just a kickstand sort of bike.

BB corrosion, before and after

Speaking of the Stronglight cranks, they were one of the few bits that really just had some surface grime on them, so they cleaned up with very little effort. I did, however, have to pick up new chainring bolts since the originals were pretty far gone.

Stronglight cranks, before and after

The cranks and chainrings were just quickly dismantled and hit with a bit of Mother's polish and they came out wonderfully. The alloy rings look like they've seen very few miles. Even the black plastic chainguard cleaned up well and was reused.

The front derailleur is Peugeot branded but probably made by Simplex. The Peugeot sticker is a little yellowed, but that's just seems like a bit of patina.

The derailleur itself polished right up and works well. The old chain was a goner, though, so a new KMC silver-finished chain is in place now.

Front derailleur, before and after

The pedals looked absolutely terrible but they spun freely, had no end-play, and were fairly lightweight. They clearly must have been decent quality when new, and comparable new pedals would be out of the budget for this bike, if I could even find them. So I tried cleaning them up, with OK results.

Pedals, before and after

They're far from perfect, but they don't look bad and they still work very well. Of course I went ahead and repacked them with grease. Since pedals tend to get pretty abused, I chose some higher-quality Finish Line grease.

For polishing the pedals and other tight areas where my stubby fingers don't really fit, I picked up a new rotary tool with a flexible shaft extension and it's been one of my smarter recent tool purchases. It's so much easier than trying to polish everything by hand, and this particular rotary tool has impressed me more than several more expensive ones I've had in the past.

It made a huge difference on the hubs and rims. Trying to polish around spokes isn't fun, but the flexible shaft made it go much better.

Rear hub, before and after

The Peugeot had Malliard hubs mated to Rigida rims, with Speidel quick-releases. All decent enough, but they were in terrible shape, with a cruddy gray haze everywhere that wasn't covered in oily grime.

The quick releases in particular were pretty rusty. A hard scrubbing with light oil and blue Scotch-brite pads took the rust off, and then they cleaned up well.

Of course I had to buy yet another freewheel tool to remove the Atom cluster for cleaning, and to remove the ugly yellowed plastic pie plate.

The rims were a complete surprise. As I got the grime off I could see that they had a chrome-ish finish. At first I thought -- and fretted -- that they were steel rims.

I was completely surprised to discover that they're definitely aluminum but had apparently originally been highly polished. I was just bringing the shine back to them. Regardless, they look great now.

Rigida rims, before and after

Tires are Schwalbe HS159 with gum walls, because I had them in the parts bin already and they're 27". If I had to buy tires I would have picked Panaracer Paselas in 27", but the Schwalbes are fine and durable.

The original chrome sticker chain stay was looking ragged, so I picked up a Peugeot-branded one from eBay.

Rear chain stays, before and after

I mistakenly thought the new chainstay protector would be hard chromed plastic, not a thin vinyl sticker, but it works. I also really like the white cables against the metallic French blue paint.

The rear derailleur was an adventure. These old Simplex derailleurs have a reputation for brittle pulley wheels, and my pulley wheel came to me in pieces inside a plastic bag helfully taped to the spokes.

Of course Simplex pulleys are complete unobtainium and the Shimano pulleys I already had laying around don't fit.

After doing some research I learned Suntour pulleys can fit, with some work. I thought it would be simple enough to find a ragged Suntour derailleur to scavenge a pulley from, but then I couldn't find one for a reasonable price.

In the end, it was faster/cheaper/easier to just get a different derailleur, and I found a nice Shimano 105 on eBay for a good price. Then I still had to buy a new hanger because the original was made for the Simplex, which of course uses a different size bolt.

Rear derailleur, now Shimano 105.

I'm happy with the results. The 105 doesn't look too out of place to my eyes and it shifts fantastically.

Taking a look from the rear, the finished Peugeot shows little touches that weren't readily visible, like a nicely fluted seatpost that polished up well.

Even the seat post bolt was pretty nasty, but it came back surprisingly well with crubby pads, light oil and elbow grease make magic.

A brand-new vintage-style Selle Italia saddle in white (of course) makes a lovely and comfortable topper for all of it. Over the seat you can catch a glimpse of the new cockpit, too.

Rear view of seat and post.

Taking a closer look at the cockpit, about all the stayed was the original stem and the headset.

The headset needed some light rust removal but the races looked good, so no problems there. The headset spacers had darkened with age, but polished aluminum replacements fixed that.

The original stem took a fine shine, but the stem-mounted shifters went into the parts bin, along with the bars and brake levers, all to make way for converting the original drop-bar configuration to upright bars.

A view of the stem and headset

The original-looking celo bar tape went into the trash -- what was left of it, anyway. In their place I fitted Origin8 bars and Tektro FL750 brake levers, same as on the Principessa.

Shifting duties are handled by some Shimano Tourney units, which work shockingly well for the price: $20 for both sides! They work perfectly with the original 2x12 gearing setup, and even have a little blue upshift button that complements the blue paint. I was really surprised at how nice these admittedly bargain-basement shifters turned out.

Grips are simply SRAM cork bar tape in white. I was going to lacquer them but in the end didn't bother. Even clear lacquer would have yellowed them some, and honestly, if they get that dirty, I can just re-wrap them. One box of bar tape would wrap them 2-4 times.

Bar plugs are courtesy of Kendall-Jackson. More on that in an upcoming post.

Cockpit before and after.

So how does it ride? Wonderfully. It's a beautiful little ride. It's very comfortable, with quick but not flighty handling. The mixte frame looks fantastic, it's easy to get on and off and it's very flingable -- but again, not squirrelly.

It feels like you could ride it all day but you'd have to stop frequently to just enjoy the day with it.

It may have been a surprisingly great bike back in the day, or maybe it's way more than the sum of its parts. Either way, I love this thing. It is, in every sense, a lovely bike. I'm glad it didn't go to the dumpster.

Made in France.

Before and after.

July 2021 - Goodbye Peugeot

I kept the Peugeot until late July of 2021 before letting it go to make room for another project. To be honest, almost immediately I regretted letting it go, and that feeling has only intensified since. It remains possibly the prettiest, friendliest commuter/city bike I've built up yet, and I would gladly build up another Peugeot someday. Preferable a mixte.

Beautiful bike.

Trek 520

2022-07-18T00:00:00Z

For a good chunk of the 80s, touring bikes were a big deal, and most every manufacturer was tripping over themselves trying to one up eveyrone else in the segment. Bike stores were glutted with high quality, supremely comfortable touring bikes with wildly wide-range gearing, high quality steel and mounts galore. It was a lot like today's gravel and endurance bike craze. At least until the bottom fell out.

In the summer of 2021 I decided I wanted one of these classic tourers, and few are more classic than the Trek 520, which had a remarkable 40-year production run from 1983 to 2023.

And so I found this one -- an '88 or '89 model -- and it came home with me.

It looks better in photos than it actually was, but you gotta love the old-school foam grips and toeclips.

A closer look shows how it really was. The brakes were destroying the gumwall tires, everything was dirty and crusty, and all the cables were rusty.

Up front, things weren't looking much better.

I never did figure out what the hose clamp on the stem was all about.

Once it was on the rack and I started taking it apart I couldn't help but notice all the neat details and craftsmanship the Wisconsin Treks were known for, like these lovely proprietary cast dropouts, and the shifter-cable running through the chainstay.

I did spend a fair bit of time giving it a deep clean and polish.

I didn't do a lot of parts swapping and modernization on this one. Underneath the grime, they were pretty decent parts, and actually turned out to be in good shape after they were cleaned up and lubed. I swapped out the seat to a Serfas I had, fitted some Panaracer Pasela tires, and just didn't make a lot of other changes. I even kept the original 27" wheels and downtube shifters.

Thoroughly cleaned and lubed, pretty close to when it was new.

Trek specced an interesting mix of 105 and Deore components for the 520. Back then, Deore was known mostly as a touring bike groupset.

These scuffs by the rear derailleur were about the only blemishes in the paint, and I came to see them more as beauty marks, so I didn't attempt to touch them up and instead just put some clear-coat over them to keep the rust at bay. Also, the early Deore derailleurs Trek used are incredibly capable, even today, for anything up to 10 speed and 36 teeth. Amazing, given how old they are.

The cast seat lug and arched brake bridge were other lovely details typical of Trek back then.

I just rode it and rode it, enjoying it as Trek had intended all those years ago, while my wrenching attention shifted to another Trek (the 640 photo-bombing above) and a Schwinn LeTour. The 520 just did what it was built to do: gobble up miles with comfort. I loved the way this bike rode.

No matter where I took it, or what I asked of it, the 520 was happy to oblige.

Dirt, water, it didn't care.

There was just one problem: the Trek was much bigger than it looked. At first I couldn't figure it out... I mean, look at that frame, it's tiny.

And then the math started to make sense: 27" wheels, plus lots of clearance for big tires and fenders, and you start pushing things up. So the 520s tiny 50cm-ish frame had a standover more like a 54 cm frame. I was comfortable riding it, but not so much when I had to stop. It just felt too big for me, so I decided to let it go.

I still miss it, though. It was a great bike that I just couldn't get 100% comfortable on. Someday I may get another one with 700c wheels and see if it fits a bit better.

I understand the buyer was intending to ride it across Missouri on the Katy Trail. It was built for that, so I'm happy it found a good home.

Magnificent.

Making wine cork handlebar plugs

2023-02-22T00:00:00Z

Making your own custom handlebar plugs from wine corks is a nice and easy way of recycling an old cork or two while showing some individuality.

It's also an easy fix for handlebars that have a very small internal handlebar diameter, which can be hard to match with off-the-shelf plugs -- something that happens fairly often with cheaper aluminum bars.

I've made handlebar plugs from wine corks for quite a few bikes now, and feel like I have the technique down enough to share.

First, you'll need a wine cork, of course. Any cork will work with more or less the same steps, so I'll leave the wine cork acquistion to you.

For bars with larger internal diamters a champagne cork may work better, albeit with a bit more effort. The basic steps are pretty much the same.

Once you have a wine cork in hand and are sober enough to wield a razor knife, then proceed:

Take your standard wine cork and cut it in half with a sharp razor knife. This will let you easily make plugs for both sides from a single cork. Of course, if you want to have different corks on each side, you can do that. It doesn't really matter.

Put the razor knife flat to your table surface and hold it there firmly. Then put your cork's uncut side down to the table surface, with the cork up to the knife blade. Once in position, carefully cut a groove in the cork by rotating it around the blade. You shouldn't need to move the blade -- just keep it steady and carefully rotate the cork to put a groove in it. If you're using a champagne cork you may want to skip this step and just cut down to the mushroom-y end of the cork in the next step.

You'll want to cut the groove down to approximately the inside diameter of the bar. If you don't get it quite right, it's OK. Once your groove is cut, carefully slice downward from the cut end of the cork toward your groove, making your way around the cork. Don't overshoot the groove or the visible part of the cork will be damaged. Continue until you've shaved off enough for the cork to fit in the bars. Again, be careful, take your time, and don't cut yourself.

When you're finished, you'll have a sort of mushroom-shaped cork with a nice edge and outer face. Pop it in the bars as you would any other bar end plug. If you want, you can shellac the cork with the grips, or without, to better protect and color the cork. Or just leave it natural. Either way is fine, and it's your call.

The electric Schwinn

2023-03-02T00:00:00Z

I found myself interested in trying out an e-bike. That's how it often starts: idly wondering if something is as fun or interesting as people say it is. It's this idle wondering that will eventually get me to try pickleball.

But on this day, it was e-bikes. And as my mind idly wandered -- and as I looked at the cost of factory e-bikes, I started thinking more and more about a conversion kit. It didn't hurt that I'd just renovated a '76 Schwinn Speedster, which heavy and overbuilt in a way that only the Chicago-built Schwinns can be. In other words, plenty strong enough for an e-bike conversion kit. I also thought the Scwhinn's three-speed, internal-gear hub might be a nice pairing with the extra power.

Because I'm cheap, because it was an experiment, and also because I wasn't much interested in maximum range or top speed, I went with a pretty basic, inexpensive kit. I believe I used this Voilamart front-wheel kit or something very similar. The kits seem to change often, but that's pretty comparable. I also bought a compatible 36V battery. I can't recall which one, but it was similar to this one. In 2022, the kit and battery were a smidge over $500. The prices have dropped quite a bit though, and now I think you could do it for much less.

The starting point for this project.

Initially, I thought I'd mount the battery on the downtube, but this proved to be both ugly and impractical on this size frame. I eventually decided to put both the controller and battery in a classic Wald wire basket out front.

The fork drop-outs had to be filed slightly to fit the oversize axle on the ebike motor. I had also hoped to run the wiring up through the tubular fork, but couldn't manage to fish it through at the fork crown. So zip ties came to the rescue. You can also see the e-bike kit throttle and wiring, right by the original 3-speed shifter.

I also had to drill out the mounting holes for the Wald rack a lot to fit the oversize axle. Here you can see one size enlarged and the other still in the original size.

With the rack and wheel in place, it was ready for wiring.

I did a test fit to be sure the electric bits were going to fit.

I had a cheap IKEA backpack that coincidentally fit the Wald basket perfectly and hid all the electric parts. You can also see the brake levers have changed. That's because the e-bike kit cuts power when you use the brakes, so you have to use their levers.

And that was pretty much it. I don't appear to have any pictures of the wiring, mostly because it was nearly plug and play. I do recall having to change one connector to make the battery and controller compatible, but other than that it was really just plugging things in. I did put some cable wrap on the wires to keep them tidy. But it was all pretty simple, and the instructions were decent enough.

How does it ride?

Pretty great, mostly. There's a LOT of weight up front on this thing, so at very slow speeds the steering is heavy and floppy. But once you get going a little, it rides great. It's very smooth and very comfortable.

As I hoped, the motor and the three-speed work great together, and hills are no longer a concern. It is definitely a heavyweight -- probably north of 50 pounds -- but if the motor is moving it, you just don't care. I've taken it on 25-mile+ rides and would go farther, but at some point I get worried about the battery dying. I would not want to be batteryless on this bike and trying to ride it 20 miles home.

All done and ready to go.

What did I learn, and what would I do differently?

I learned these kits are pretty straighforward and well within the ability of anyone reasonably handy with a wrench and able to figure things out. Probably the biggest thing I think makes a difference in the conversion is thinking really hard about where the battery and controller will be stored, and what implications that has for wiring, weight, and handling. I've enjoyed mine and would make another. That said, if I were to do another here's what I'd change:

I'd consider a hybrid frame, or an old hardtail mountain bike. Either would be much lighter than the Schwinn, but more importantly they'd have a JIS-standard bottom bracket rather than the larger "american" bottom bracket on the Schwinn. This would make it easier to put in a mid-mount engine, which I think would be preferable.
I'd keep an internal-gear hub, but look at maybe a 7 or 8-speed hub. But that's me. I have no reason to believe a derailleur wouldn't work fine.
I'd add the pedal assist feature. This kit came with pedal-assist, but it was another casualty of the Schwinn's oversize bottom bracket.
I'd focus harder on the brakes. They're adequate on the Schwinn -- I upgraded them in the rebuild process -- but even a 36V motor can get you up to speeds where you really want good brakes.

Fun bike. I should ride it more.

April 11 update

I've decided I need to clear the herd a bit, so this one is hitting the market. To that end I stripped off the e-bike conversion kit and took it back to more of a BMX Cruiser/Klunker vibe. And when I rode it, it was suddenly my favorite cruiser ever. Such a fun, fun bike. I'm still going to sell it because I really do need to clear a few out, but I can tell I'm going to regret letting this one go, and sooner or later I'll end up building another one much like it.

It just looks cool, in all of its late 70s/early 80s cruiser glory.

Modern klunker-style bars and a pretty good reproduction of an 80s BMX stem.

80's style tubular fork and reproduction Dia-Compe MX brakes

Original cranks and Schwinn chainring, with new gold chain.

Maturity Model Generator

2023-08-08T00:00:00Z

Maturity Model Generator

In 2022 or so, it seemed like everywhere I turned there was either a maturity model popping up for something, or someone was calling for a maturity model. Something was in the air, and it seemed like we needed a maturity model for everything. Cheeseburgers were getting a maturity model.

Naturally, half these maturity models were pretty much nonsense, full of big words to let the author of the maturity model feel like they had Thought Deeply About Things and nearly completely ignored by everyone.

I realized long ago that if you're going to write volumes of nonsense that no one will ever read or act on, it's best to have a computer do it for you. Armed with that knowledge, I could have been on the forefront of AI, but instead I dithered about and hacked this thing together as my own little in-joke.

And also because I wanted to play with Alpine.js and HTMX, but mostly because I just thought it was funny. So I ended up with this....

A sample generated maturity model, featuring levels such as 'sophistimicated', 'sentimonies', and 'unfaceuptoable'.

The maturity model names and text are mostly a mixture of business jargon and made-up words from the Simpsons, with a few of my own additions. The colors sort of map along the lines of "green is good" and "red is bad" to make it more in line with stereotypical maturity models. Of course that also makes it pretty inaccessible, among other problems, and I should call that out.

At any rate, it's dumb, but no dumber than a lot of "real" maturity models I've seen.

An interesting footnote, though, is that since building it, I've actually developed an appreciation for a well-crafted maturity model. You can usually tell the good ones because they illuminate rather than obfuscate.

Why did I do it?

To learn some mini JS frameworks, and because I thought I was being funny.

What did I learn?

Alpine.js and HTMX
Some tricks to have semi-random CSS colors that still fell within predictable guidelines.
Maturity models aren't all bad. Just the bad ones.

Where is it?

The Luxus folding bike restoration

2023-09-16T00:00:00Z

I've never been overly cursed with good sense, especially when it comes to projects. If there is a lost cause, I'll find it. If there is a hopeless case, I'll take it on.

I should have learned my lesson from the Peugeot rebuild and found a nice easy project.

I should know to watch my local market and pay attention to what sells and what doesn't.

Did I do either of those things? Nope.

The Luxus, as found on the local marketplace site.

I got it into my head that I wanted a vintage folding bike, and then I had to have one.

Why? Beats me. I think I began to see old Italian Chiordas and Bianchi Nealeco's as a different sort of fun. I appreciate the cleverness of the rear stays forming a useful rack. Maybe I just wanted something to take camping.

Regardless, I read Sheldon Brown's love letter to the Raleigh Twenty, noticed it said the other european folding bikes of the era were generally much lower quality, and then I promptly went out and bought one of the lower quality examples: a Luxus Sportbike.

So what is a Luxus Sportbike? Who knows. It's labelled as being from West Germany, and per this page it may have been manufactured by any number of companies at the time. It may not even have been made in West Germany at all.

Here's what we do know:

It bears some resemblance to some better-known vintage folding bikes with the way the stays loop around to form a rack, but it also appears to differ from each of them in the details.
Luxus did make other bikes, although details (at least in English) are sparse. I have managed to find examples of road bikes, utility bikes and an interesting motocross-inspired kid's bike.
This particular one isn't technically a folding bike. There is no hinge at the middle, so it technically collapses into two parts.
This thing is unbelievably heavy. Somehow, this little thing weighs in at 34 pounds, about the same as the Raleigh Sports I rehabbed last year.
The particular example I bought is in miserable shape.

Since the market for used folding bikes is nearly non-existent, of course my plan is to throw parts and money at this one. I want to pick up a kids' bike with some 20" alloy wheels, try to lighten up the weight, and just generally see if I can make this thing decent to ride. No matter what, it'll be interesting.

So, with that in mind, I started tearing it down.

Once I got it home I could take stock. It's filthy and the paint is in bad shape, but it's mostly complete. I was surprised neither the stem nor seatpost had seized.

Originally it was wired through the frame to run front and rear lights. The generator and front light are long gone, and I'm not sure how the wiring worked given that the frame separates.

The headbadge decal IDs it as a Luxus Sport 72, made in West Germany, for whatever that's worth.

The 'sportbike' decal on the main tube is pretty ragged. It hardly matters, since this thing needs a full respray. I am wondering if I can get Luxus decals. I haven't looked yet.

The rear fender had a hard life but I think it can be straightened out and useful again. The rear light, however, appears to be a goner. I need to decide if I'm keeping the wiring.

The chainguard has surface corrosion but it's straight and can also be re-used. Honestly, all of it looks like it could be re-used, but there's no way I'm keeping those cottered cranks.

The rack really is a clever bit of design and appears very useable.

It's the same story at the forks: cosmetically a mess but all more or less solid. Even the fender looks salvageable.

This star knob makes unclampling the two sections pretty straightforward. I think I can clean it up.

The seatpost clamp uses a plastic wingnut as an early take on making a quick-release. Again, a clever detail.

Up front another star knob is used to quickly adjust and tighten the long quill stem.

Unclamped, you can see the two parts are completely separate. When the wiring was in place I'm not sure how this worked: Did that tiny wire just tie the two halves together?

The pump peg is another delightful detail. I wonder what the very short pump looked like when new, and how the other end clamped onto the oversized and curved main tube.

The headset had no discernible grease, and didn't appear to have had any grease in a long, long time. That probably explains why it made graunchy, gravelly sounds. The whole headset will have to be replaced.

The bottom bracket looked no better. I was surprised the crankarm cotter came off pretty easily, but the bottom bracket looked like it was stuffed full of bog muck.

February 2021: Cleaning and sanding the Luxus

The Luxus folding bike frame was in rough shape, and I could tell when I was tearing it down it was going to take a full respray. What I wasn't really prepared for was how much work simply cleaning it would be.

I'm not sure if it had been inside a smoker's home, or if it was just age and neglect, or whatever else the cause may be, but the frame was covered in a smelly, irritating funk. And of course I had to use some of the most noxious chemicals in the house to cut through the gunk, making it a doubly unpleasant job.

And it's way, way too cold and snowy to take it outside. So I've just been gutting it out, wearing a mask and nitrile gloves, and taking it in small doses.

The grime is gone. The first round of sanding is complete. I've treated the frame with a phosphoric acid based rust converter, which takes ferric oxide and chemically converts it to something paintable. The rust just turns black, and it's gone. This is great stuff for stopping rust in its tracks and prepping for paint. Just wear gloves, and a mask.

It's slow going and there's probably a fair bit of sanding left, but I'm starting to get it under control.

The rear half, right after the teardown, showing a lot of scrapes, rust and grime.

The rear half, after the first round of cleaning and light sanding. I still have to remove stickers and it needs a lot more sanding.

The fork was similar: a mix of broken-down decals, scraped paint and dirt.

With the decals removed, plus a lot of scrubbing and the initial sanding done, I brushed the entire frame with phosphoric-acid-based rust converter.

March 2021: Bad conditions and worse paint

Successful spray painting really requires a pretty narrow temperature band. So of course I decided to spray paint the Luxus folding bike in the dead of winter. It went about as well as you'd expect.

Sportbike bits on the sawhorses getting the first round of paint.

Everything started well enough. A few unseasonably warm days in February gave me a good opportunity to get it sprayed, and I took it. I was cooking along and the frame was looking good when disaster struck: on the last coat the paint crinkled. I had violated a second rule of painting and mixed paints. They did not get along well.

So after spraying and wet-sanding multiple coats, I now had to strip it all back. Honestly, taking after it with a stripping wheel may have been overkill. It's possible I could have just sanded it back. But at this point I didn't trust my base paint anymore.

Taking all that new paint back off

Of course, by the time I'd stripped it all back the weather had turned. Painting outside was no longer an option.

Luckily the individual parts of the Luxus aren't very large, so I took a large plastic tub and improvised a small spray booth. I don't really recommend this. It's hard to get adequate ventilation, and there will be overspray. It worked okay for me, but really, you probably shouldn't try this at home.

The plastic tub

It was slow going, too, since I could only paint small portions at a time. Add in wet-sanding between coats and painting this little frame took a long, long time.

Wet sanding kept finding more defects, so I'd sand and spray, sand and spray, spray and sand.

Because I had sanded back the first respray attempt, and I had more defects than usual from working in the cramped corners, I wet-sanded pretty aggressively between coats to get the best possible surface. For paint I was using a Rustoleum performance enamel which worked well, especially coupled with a good (and compatible) primer. But still, if you want a really good coat, you've got to wet-sand and polish.

With enough elbow grease it started coming together, finally. At this point the painting and sanding are done, and I've gone over it with Turtle Wax Rubbing Compound and then polishing compound. I may give a few areas a bit more polishing, but it's looking good.

While my paint was drying I polished up the original chrome chainguard, and had a go at straightening a few wobbles in it. I'm no metalworker and it remains not-quite-straight. But also not bad. With it sitting in place you can finally start seeing it all come together.

The one upside to the long and painful painting process was that I had time to find a new bottom bracket, which was an adventure. You see, the bottom bracket on this thing was strange: smaller than an American BB as found on, say, a Schwinn cruiser, but larger than a normal square taper BB. And it was push fit. After a lot of digging I came to learn it's called a Thompson bottom bracket, and they're relatively common on Dutch city bikes. Who knew! So I made my best guesstimate on what the best spindle size would be to replace the cottered cranks and ordered one from Holland. And then I waited while it came all the way from Holland.

Almost there

While the bottom bracket was tricky, I got completely lucky stumbling across some reproduction Luxus stickers being offered by a European seller on eBay. While they weren't an exact match I was happy to even get anything in the ballpark and I thought they looked great on the bike, especially with the new red paint.

As I started putting it back together, the first thing to do was install a new Tange headset to connect the frame and fork together. The second thing was to renovate the frame clamp knob with some white Plasti-Dip.

At this point buffing and polishing was complete and a new Tange headset was in place, along with the headstock decal.

Polishing up the fenders took a mix of a rubber eraser wheel on the drill, fine steel wool, polishing compound, pliers and a hammer. And elbow grease. Still, they came up pretty nice.

May 2021: The wheels go round and round.

By spring I had most of the rebuild under control. I was still trying to trim the Luxus' formidable weight by upgrading the original steel parts to aluminum where I could. The wheels in particular were a problem area. The originals weighed a ton and were completely shot anyway, so they had to be replaced. But as I learned most 20" wheels with coaster brakes have steel rims -- not an upgrade. I kept my eye on the market, though, and eventually found a cheap Schwinn with decent wheels.

Test-fitting the progress so far. The decals are on, and the frame clamp wheel has been plasti-dipped, so the frame looks complete-ish. I've got the rear fender polished and on, but not the front. And I've got a new alloy stem replacing the original steel unit, but some bullhorn handlebars did not stick around past the test fitting.

The original steel wheels were in terrible shape and incredibly heavy for 20-inch rims. This discarded kids' Schwinn was a cheap way to some half-decent aluminum rims. Because the Luxus had no mounts for rim brakes -- and cabling would have been a nightmare with the brakeaway frome -- I had to keep find aluminum wheels with a coaster brake. That was harder than you'd think.

With the wheels cleaned up and rebuilt, and a new pair of white tires, it was time for the second test fit. By this time I had the retro-style LED headlight on and had settled on some Velo Orange North Road bars.

And with a little more fiddling, that pretty much wrapped it up, just in time for camping season. It fits easily in our tiny camper!

However, when we took it camping, we learned it was missing a key accessory: a Fireball basket. So we remedied that.

September 2023

After a few years of enjoying the Luxus, I found that I had too many bikes cluttering the garage and my interest in camping was waning. It was time for it to go. Luckily, JC, the nice fella that runs Kansas City's Bright Lights for Kids Charity Ride spotted it and had to have it. So the deal was done. And somewhere out there in the world there is a (staged) picture of me riding it across the finish line at the ride!

The giant list of questions to ask employers

2024-01-07T00:00:00Z

In May of 2021 I was working at 18F in a term-limited role, so I was actively interviewing. As I interviewed I realized that companies always asked me if I had any questions for them, and more often than not I completely froze and couldn't think of any questions at all in that moment. Not a great look.

So I started compiling good questions. But the recovering journalist inside me knows: with any interview, a good question alone isn't enough. You need to understand why you're asking the question and what you hope to learn from it. So as I compiled the questions, I added notes on scenarios in which it might be a useful question and signals -- both good and bad -- to watch for.

Over time it's grown to be a pretty large collection I've kept on Github. It will remain there, but I'm also embedding it here as a convenience.

Questions for potential employers

This is a big collection of questions I've gathered over the years that have proven to be useful when interviewing, including why you might want to ask the question. Remember, in any interview you're trying to get to know the company and the people you might be working with as much as they're trying to get to know you. Maybe more.

There are a lot of questions here. Some are just simple nuts-and-bolts questions. Some are only appropriate for certain types of companies. Some might help after you've already got a whiff of an org smell. You'll never ask all of these -- there's no time! But usually, after you've read the role description and had a phone screen, you should have a pretty good idea of which questions you want to highlight and ask.

I've broken them out by subject matter, with some notes on things to look for.

If you'd like more questions for director-and-above positions, Jacob Kaplan-Moss has a great list.

Getting started

What is the onboarding process like?
Do they have one? How well-defined is it? Do they have a "buddy system" or some other mechanisms to help you get ramped up, or do they just let you sink or swim?

In the first 60 to 90 days of employment, what would be my most urgent priorities?
This is helpful for getting past the position description to the real expectations of the work. Plus the first 90 days are critical.

What are the key accomplishments you’d like to see in this role over the next year?
What is the one thing I absolutely must get right the first year?
This one extends on the previous question, looking longer term. This helps you get a sense of what your success criteria would be as well as how well the employer has defined the role. This one can also help get a better sense of the real priorities, which may differ from what the role description indicated. If they don't have clear answers to either of these questions, the role is probably poorly defined and not set up for success.

What does success look like for your customers for someone in this role?
A good question to help get a sense of how user-focused the organization is.

Culture

What type of people are successful here? What type of people are not?
Alternate: What characteristics do the people who are most celebrated have in common with each other? Conversely, what are the characteristics that are common to the promising people you hired, but who then flamed out and failed or left? Pay close attention to this one. You can potentially pick up a lot of red flags about what type of culture they really have versus what kind of culture they want you to think they have. The phrase "culture fit" itself can be a warning sign of homogenous, non-inclusive, bro-grammer culture.

How do you determine if someone is a poor fit for the company?
Same as above, they may tell you more than they mean to about what they value (and what they don't).

If an employee does something harmful that isn't a fireable offense, how do you handle that?
What steps do you take to create a culture of accountability?
They should have a plan for this. If they don't, any number of toxic-but-not-fireable behaviors are probably not being addressed.

Is there any sort of institutionalized way of dealing with plateauing or preventing burnout?
You should hear something about rotation of duties or location, sabbaticals, etc. In other words, a real plan for avoiding burnout, not empty platitudes. Follow-up: Is it possible to take sabbaticals or unpaid vacation?

How does internal communication work? How does the company communicate with itself, and is that effective?
This can be a really telling question. Are company communications scattered? Leaked out? Top down? How does it work? Does it work?

Are there catered suppers?
This may sound like a nice perk, but you may want to learn more about why it's necessary. In a properly functioning organization with normal 8-5 or 9-5 hours, you should be home for supper. In crunch times it's nice when the organization brings in some decent food, but does the org find itself in crunch times all the time? If so, why?

What is your turnover rate?
How many people were hired last year and how many left? Over the past 2-3 years? What is the average time that people stay at the company? Attrition is one of the strongest tells that a culture is bad. If more than 30% of the company left in the past year, that's a real problem. What is the company doing about it?

How are disagreements solved? What happens when personalities clash?
You're looking for a real, equitable and fair plan here, not a handwave-y answer.

Given everything you like about the company culture, what's the flip side? What failure modes do you think your culture creates? Are those potential failure modes or have you seen them happen? How do you try to guard against them?
Even great cultural choices have downsides. If the person who's answering you has been in the company for a while and can't give you a good answer, either they're unwilling to give you bad news about the company, or they're not very thoughtful about the culture and its failure modes.

Work/life balance

How many hours a week does senior management work?
Do they put in 80-hour weeks? If so, run away.

How much vacation do people get?
If there's "unlimited" vacation, how much vacation do people normally take? What is the expectation for "excessive" vacation? There is always a number.

What holidays are observed?
Some companies do not observe federal and state holidays. For parents, this can be a real problem since schools usually do. If so, you may have to use a vacation day for your child's holiday.

Does this position require travel? How often?
This should have been in the job post, but if it wasn't, ask about it and think about how it fits with your lifestlye and commitments. Some folks are fine being road warriors, but if you've got kids or other commitments at home, it can be difficult.

Would I need to be on call? How often?
Another nuts-and-bolts question, but on-call rotations can be tough. While you're asking, consider asking of being on-call comes with extra compensation.

How many hours do people work in an average week? What time do people normally leave work? What time do they normally start? Do people work on the weekend? Seriously, if the job can't be done in 40 hours, more or less, something is probably wrong.

Do people check in when they're on vacation?
They shouldn't, and they shouldn't be expected to. Take the vacation.

What kinds of tasks are routinely demanded of by management beyond the original job description?
This can be a bit confrontational, or can sound like you want to do nothing more than what's explicitly in the job description. Be careful with it. Still, it can be useful if you're concerned you may be asked to walk your manager's dog or something weird.

What is the rhythm to the work?
Is there a time that's “all hands on deck” and everyone pulls all-nighters, or is it pretty consistent throughout the year?

How often are there emergencies or times when people have to work extra hours?
For most orgs, the number of emergencies and unplanned extra hours should be near zero. Generally speaking, emergencies indicate either faulty DevOps or faulty management. There are times and places where extra hours should be expected -- if you're involved in taxes in the U.S. in any way, you know April is busy, for example -- so it's worthwhile to differentiate planned extra hours from unplanned.

Are the company’s managers inclined to call employees at home with questions or comments?
If so, that could be an indicator of poor boundaries or a poor work-life balance. Or it could just be a busy boss trying to catch up with you. Use your judgement and ask follow-up questions if you're concerned.

Bureaucracy

Walk me through the process of expensing a $[price] [item]
Choose an item and price -- that could be a $50 book or something larger, it doesn't matter. What you're looking for here is a process that sounds reasonable and navigable for the price and item you chose.

How many layers of company managers or executives does one have to go through to get approval for a new idea?
The more layers, the more difficult and time consuming it will be. Well-defined process can mitigate the difficulty, but it is still a good indicator of overall bureaucracy and speed.

What is the policy on alternate work schedules?
Is variability okay, or is everyone expected to be on the same schedule? In modern orgs, especially distributed orgs, asking everyone to punch the clock at the same time is backwards, at best.

What is your remote work policy?
Why is that your remote work policy?

What is the company’s policy on work/life balance?
How does that work out in practice?

Is it easy to move to other divisions or offices?
Warning: the interviewer could infer that you are a difficult teammate and like to jump around.

What information is shared with the employees in terms of revenue, costs, operating metrics, etc?
Is this an “open book” shop, or do they play it closer to the vest? How is information shared? How do you get access to the information you need to be successful?

Does the company require a prospective employee to sign a non-compete contract? If so, could you explain in a few words how restrictive it is.
Is it negotiable?

Diversity, equity, inclusion, belonging, and ethics

Tell me about a situation where someone raised a concern about DE&I or ethics?
How was it handled? If not, have there really not been any? Is management listening?

Tell me about the organization leadership demographics. What specifically are you doing to drive greater diversity in management?
Bad orgs don’t know or get defensive; good orgs are open and transparent; the best orgs share what they’re doing to improve. Follow-up: What benefits do you expect from increasing diversity among leadership?

Tell me about your effort to attract a diverse pool of candidates.
What metrics are they currently using to track DE&I in hiring?

Tell me about your efforts to retain a diverse group of employees.
This is a particularly useful question. Lots of companies try to recruit diverse candidates and then don't do much at all after that to keep them. Again, what are the metrics they're using to track this?

Tell me about a time when a challenge or suggestion from an under-represented group was acted on in their favor?
How long ago was that?

How transparent is your salary and compensation data?
Not long ago, most orgs did not share salary and compensation info at all. State salary transparency laws have been changing that, but the information can still be vague or misleading. The best orgs will understand why salary transparency is valuable.

Am I the only one [in the demographic or under-represented group I identify as a member of]?
If so, how do you plan to do to ensure that I am welcome, included and equal?
Incorrect answers include blinking in confusion, saying "everything's fine and we don't see why we'd have to do anything in particular", and "you're not the only one; we have a [person] in a $other_role!" Follow-up: Where do you anticipate challenges?

Do you have a standard insurance package that covers trans health care?
Even if you yourself might not use the insurance package, this still gives you good insight into their commitment to inclusion.

Do you offer paternity leave, or just maternity leave?
If they only offer maternity leave it can say a lot about the roles they expect women to play.

Most/all of my interviewers were men. Can I speak to someone else on the team to hear more about their own experience?
Does the team lacks diverse perspectives?

Understanding the company and team

How are your teams structured? What is the management structure like?
Pay particular attention if you have any questions about reporting or power structures. Get clarity.

What’s the biggest challenge the team has gone through in the last year? Does the team currently feel optimistic about what's next?
Useful for getting a sense of team morale and working conditions.

Is this a new role?
If so, follow up with more questions about how the company plans to get buy-in for this new role and support the people in it. This can be useful to understand how well-defined the position is and if it's a position set up for success. If it is not a new role, see if you can learn more about why the person left. Best case is they were promoted up, meaning this role can lead to similar opportunities for you. Follow-ups:

If this is a replacement position, what happened to the former employee? How long were they in the role?
If it's a new position, how is the company supporting it? What does success look like?

How does the organization reward employees?
Is it a star system / team-oriented / equity-based / bonus-based / golf-clap-based? Does it reward individual performance? Team performance? Is the reward tangible and real? How does the company demonstrate to an employee that they are an asset to the company? Follow-ups:

Why is that your reward system?
If you could change any one thing about it, what would it be?

What has you most worried?
What keeps you up at night? A competitor? Something else?

What’s one thing that’s key to this company’s success that somebody from outside the company wouldn’t know about?
Can help you set priorities as you onboard.

What do you wish you had known when you joined this company?
Can tell you a lot about the culture or challenges.

What would you say are the company’s strengths?
Alternately, what would you say are the company’s weaknesses? It can be illuminating to flip these traditional interview questions back on the company.

What is the company’s current strategy for generating new business? What is the company’s strategy for maintaining existing business?
This speaks to the viability of the business model and is particularly useful for start-ups/scale-ups.

Are you profitable? if not, how does this affect what you can do? What's your planned timeline for becoming profitable?
Again, particularly useful for startups. Don't ask a publicly traded company this. It will just show you didn't do any research on readily available information.

How do you make money?
Again, mostly for startups, but can they explain the business model in a way that makes sense?

Are company financials transparent throughout the company?
What about salaries? (see the DE&I section). This is another question that you probably don't want to ask a publicly traded company, because the financials should be public record. If you're curious, you should probably have already checked.

How much are you planning to hire in the next year?
If it's a large number, ask the follow-up: How do you plan to hire and onboard that many people?

How does the company usually solve problems: through committee, group meetings, individual meetings or management only?
Are they consensus-driven? Top-down? How well is that working for them?

How are important decisions made and communicated?
How many people are directly or indirectly involved in creative decisions? Are they dictated top down? Are ideas from anyone welcomed? If so, in what scope/context?

How does sales / operations / technology / marketing / finance work around here?
Groups other than the one you’re interviewing for -- the interviewer should have familiarity with those groups, and should (hopefully) speak well of them.

Leadership

Do managers regularly hold 1:1s?
What about skip levels? What sort of topics are discussed?

Who would I directly report to?
In some cases, this question can help you get a better sense of the org chart and where you'd be on it. It can also be a clue on whether the org is hiring you for a specific team, or just putting you in a pool of new hires to be farmed out as needed.

What’s your (or my future boss’) leadership style?
Is that style aligned with what you're looking for in a manager?

How do you know if people are comfortable giving you candid feedback? How do you fix it if they’re not?
Does your future manager value feedback and want to know what's not working? Hopefully, this is something they've thought about.

How do you nurture psychological safety in your team? The best organizations have probably spent considerable time thinking meaningfully about how they foster psychological safety on their teams and can readily articulate actions they've taken. Plenty of good organizations may not have thought about it in those terms -- they may lack the vocabulary -- but when prompted can still articulate what they've done. However, if get a blank stare or dismissiveness, even after prompting, that can indicate a toxic or hostile environment.

Doing the work

How does work get assigned?

How often do inexperienced people get to work directly with more experienced people?
And how so? Pairing, or something else? How does it work?

How do you balance support and feature development?

Tell me about your cross-functional teams
Do they have dedicated designers? Product owners? QA? Technical writer? Dev manager? How cross-functional teams are built tells you a lot about what the company values enough to put on the team.

How often do you have meetings? Are there scheduled/standing meetings? How much time should I expect to be in meetings
Remember, though, that for some positions (especially senior positions) meetings are a core component of the job.

When something goes wrong, how do you handle it?

What kind of tools are provided by management to help an me do my job? (machinery, computers, office supplies, etc.)?
How often is this equipment updated?

Career development

Are employees encouraged to go speak at conferences?
Do you cover travel to conferences?

Does your company support continuing education?
If so, how (and how much?)

In what other ways do you support career development?

Does the company routinely provide training, either internal or external, for new technologies such as software updates or best practices?

Does the company allow employees to pursue their own training path
To what extent?

When was the last time you promoted someone on your team? How did it happen?
How are they likely to handle it when you want a promotion?

Tell me about a time you supported a direct report leaving your team or company for the benefit of their own growth?
A supportive manager cares about your goals, not gluing you to your seat. The very best managers realize when it's time to move you up, even if that means moving you out.

Performance evaluation

How is performance evaluated?
What criteria does the company use for performance reviews? On what cycle? Are these criteria documented? If not, how do you ensure fair and equitable performance reviews?

How often can I expect job performance to be reviewed by management?

Are raises based solely on job performance reviews? If not, what else is a factor?

Do you stack-rank employees? Can you tell me how your stack ranking process works?
Most times, this should be a big red flag. "Stack ranking" usually means the company smooshes everyone into a bell curve, and the people who find themselves at the wrong end of the bell curve are now "underperformers" no matter how great they may be. In other words, stack ranking companies may say "we only hire the best" but then they'll treat at least half of their employees as under-performers, by design. Note that there are companies that employ some other sorting methods they may call "stack ranking", so it's important to be sure you're working from the same definition.

Can you tell me about a time when you've had to let someone go?

Compensation

If this is an exempt (salaried) position how much overtime do you assume I would put in without compensation?

If this is an exempt (salaried) position, am I required to track all my time?
If so, how? And if it's not hourly, why?

What is the salary you expect to pay for this position?

Is there a company/employee bonus structure and if so, how does it work?

How often do you offer above asking?
Can you speak with someone who got such an offer?

For engineering orgs

What's the process for code review? How do you think about code correctness?
Bonus points if they can point to documented guidelines for behavior in code reviews.

How do you make sure that all code is understood by more than one person?

How do you find bugs in your team's code?
Testing? Something else?

What happens when you find a serious bug in production code?
If they say this doesn't happen, that's a warning sign.

Who is responsible for doing deployment? How often do you deploy?

Is there a written roadmap all developers can see?
How far into the future does it extend? How closely is it followed?

How/when do developers talk to non-developers?
How cross-functional are the teams? Is it easy to talk to the people who will be using your product?

What's your approach to technical debt?

Do you contribute to open source projects?
Which projects? Which teams work on open source? Do you work mostly in the community or do you have a private fork?

Can I see some code the team I'm interviewing for has written?
From an open-source project, for example.

Things to look for in real life

How is the office space physically organized?
Is it clean? Well kept?
Are employees expected to pay for basics (like coffee)?

With many thanks to all who have contributed to this list

Pear

2024-01-10T00:00:00Z

In late 2020 or early 2021, for a number of different reasons I decided I wanted to get a better understanding of Natural Language Processing (NLP) and Python's Natural Language Toolkit (NLTK). Maybe it's vestiges of my career in journalism, but the idea of converting a mess of text into something the machine can understand and do something useful with appeals to me.

I was also pretty interested at the time in how government resumes are evaluated, and the need to match language. So given those converging interests it just made sense for me to try NLP to compare the language in a couple of documents -- like a resumé and a job post.

And that was the beginnings of Pear. Over time I've re-written it a couple of times, built a nicer front-end for it and added functionality. I may keep doing that.

I've also found I keep reaching for it, because similar commercial systems seem highly intrusive. I'm always wary about providing data or text to most any app, especially when they seem pushy about wanting me to do so. Are they harvesting and selling information? Are they doing something else with it? What happens to my doc when I hit submit? I like having something that's non-commercial and is clearly not in it for any worrisome reason.

Why did I do it?

To learn, and to solve a simple need I had to compare docs.

What did I learn?

A whole lot about Natural Language Processing. Even at my self-taught level this stuff is fascinating.
Alpine.js and HTMX -- I'd been wanting to play with these mini-JS libraries and came away quite impressed. Would use again, and recommend.
More Flask. As a died-in-the-wool Django person, it was really interesting learning more about Flask's approach to things.

Where is it?

Not funny, Dad

2024-01-27T00:00:00Z

About every other year or so I'm reminded that the U.S. Federal government has a site called Fatherhood.gov, and tucked away inside that tiny little backwater in the vast sea of government web sites there is a collection of dad jokes. Yes, the United States government keeps and hosts a collection of dad jokes, and because they are the work the US government, they are owned by and open to the public.

How this came to be is a fascinating story. Fatherhood.gov was established as part of the National Responsible Fatherhood Clearinghouse (NRFC), which came to be through the Deficit Reduction Act of 2005.

For those who don't recall, in the mid-2000s there was a highly partisan (and arguably racially coded) panic over "responsible fatherhood" during the Bush/Cheney administration. When the DRA was rammed through Congress on a party-line vote, it authorized funds for "the development, promotion, and distribution of a media campaign to encourage the appropriate involvement of parents in the life of any child and specifically the issue of responsible fatherhood."

At some point, someone involved was smart enough to realize that all responsible fathers need a sizeable stable of dad jokes at the ready, and they were ready with a supply. And once they went into the site's CMS, providing a feed of them was trivial.

What's extraordinary is that some buzzkill bureaucrat hasn't come along and squashed it all. It's a beautiful thing when you think about it.

At any rate, inspired by this delightful bit of government arcana, I threw together a quick mashup putting the jokes together with a selection of dad-like images from Unsplash. You can see it at dadjoke.fly.dev -- at least until I move it to a more proper domain.

Originally, I had planned to pair the jokes with photos from other government resources such as the National Archives, Library of Congress or Smithsonian, but despite of my best efforts and their robust APIs I was not able to locate a suitable feed of dad photos. If anyone knows where to find them, let me know, OK?

The site itself is painfully simple. It's just a simple Flask site that tries to get a joke from fatherhood.gov (or icanhazdadjoke.com as a backup) pairs it with an image from unsplash, applies a short cache to it, and... well that's about it. There's just not much to it. Enjoy it as intended: as a silly little diversion.

Why did I do it?

Because I could and I wanted to. That's about it. There are better places to get Dad jokes, if that's your thing.

What did I learn?

Not a whole lot on such a simple site, but...

I learned about Flask's built-in caching, which I hadn't used before.
Learned a lot more about Library of Congress, Smithsonian and National Archives APIs, in spite of ultimately not using them.

Where is it?

Markitup (v2)

2024-02-08T00:00:00Z

I've used a library called MarkitUp on different projects of mine for more than 15 years. Compared to most Rich Text Editors, I found it to be much lighter weight and gave users Just Enough help to format using markdown. On the server side, this also offered nice flexibilty: I could store markdown, HTML, or both. In short, for a lot of nerdy reasons I really liked MarkitUP.

But time marches on in a way that software rarely does, and as I've spun up a new project lately -- more on that to come -- I found that not only had Markitup not really kept up with times, I couldn't find anything comparable to replace it with, either.

In a nutshell, the world had left Markitup behind. It was built for jQuery, and in 2024 browsesrs have gotten a lot better and it's hard to see a reason to use jQuery anymore. It also was bloated with a lot of code to support browsers that just aren't really used anymore.

I decided I wanted to update it. This was a foolhardy spur of the moment decision, since I don't entirely trust my modern javascript skills, either. Markitup isn't the only thing that's been left behind, I have, too.

And then I thought, hey, what if I see if ChatGPT can convert it for me? And so I did.

And it wasn't a perfect conversion, but it was pretty close. I still put in hours checking and testing, but even counting that time, it saved me hours. It was impressive.

I've recognized for awhile now that I have been lucky -- the entire cohort of engineers who came up over the last 25 years have been lucky. Software engineering has been, for all of my career and all of recent memory, a highly paid, very expensive specialist field.

This has been a historical fluke, and one the market will eventually correct. It always does. There's too much incentive to turn expensive specialities into commodities.

We are seeing the beginnings of the commoditization of software development. It had to happen. It is happening.

I don't think that's the end of the world for software developers, though. All of the best ones I've known have understood that the code is -- relatively speaking -- the easy part. The people you're building it for -- both the end users and the stakeholders -- that's the hard part.

So while I may be impressed with ChatGPTs ability to convert jQuery code, I remain less impressed with it's problem solving ability, and that's the the real value of a good developer.

But anyways, about Markitup....

Why did I do it?

Because I had a need, and because I thought it would be interesting to see how close generated code could get.

What did I learn?

Generated code gets you about 80% there and you still need a human for the remainder. But that 80% may be the difference between a problem that gets solved and one that doesn't.

Where is it?

The repo

Deploying

2024-02-13T00:00:00Z

At one time, deployments were simply uploading files via FTP. When we weren't editing live files in production. We were but simple cavedwellers, and those were interesting times.

Since then we've developed a lot more rigor in our deployments and have greatly improved their reliability, repeatability and security.

We've also introduced a lot of extra steps, and where there are extra steps, there's a sure likelihood I've missed one. Or 12.

So, for my future self, I am starting a running list of questions to ask myself as I first deploy a new application into a new environment.

Note: I recognize that many of these questions are painfully basic and some readers may feel compelled to tell me a better way of doing things. It's OK if you don't.

Did you set the environment variables in all the environments?
How did you set all the environment variables in all the environments?
How are you getting all the environment variables in all the environments?
If you put them in a flat file, did you remember to put that in .gitignore?
Did you remember to pip freeze the requirements?
Do you remember the correct command to launch the app? Hint: for fly.io, it's fly launch
Did you remember that there's a different command to deploy that app? Hint: fly deploy
Did you remember to pre-install the dependencies in your dockerfile that your app will need to put itself together?
Do you remember that you probably need to copy requirements.txt to do that for it to work?

COPY ./requirements.txt /app/requirements.txt
RUN pip install --no-cache-dir -r requirements.txt

Do you need to rebuild the app because you changed the dockerfile?
Did you forget about your database settings?
Did you figure out how you're going to send email? You know you're gonna need to send emails, right?
Did you figure out how to receive emails?
Did you remember to put the email service API keys in your secrets, too?

Why did I do it?

Because I had a need, and because I thought it would be interesting to see how close generated code could get.

What did I learn?

Generated code gets you about 80% there and you still need a human for the remainder. But that 80% may be the difference between a problem that gets solved and one that doesn't.

Where is it?

The repo

The Five Conditions for (Organizational) Improvement

2024-02-19T00:00:00Z

Back in 2017 Roy Rapoport wrote “The Five Conditions for Improvement”, talking about the conditions necessary for an employee to fix a performance problem. I think he came up with a great framework for helping people improve, but what really keeps me coming back, over and over again, is how applicable it is in larger contexts. I think what Roy really described were the five conditions necessary for any entity to improve. And that includes organizational entities.

Let’s say, the “Bob” in Roy’s essay isn’t an individual, but is instead Bob’s Organic Bagels, a scrappy start-up that has grown to become a solid little company bringing in a few million a year. They’ve reached the stage where they need to develop a little more maturity in their processes in order to scale, yet they can’t quite seem to get there. Why?

Does BOB agree there is a problem? Is there consensus across BOB senior leadership that there is a problem? What about outside the senior leadership team? If only one or two senior leaders agree there is a problem to be solved, it’s not likely to be solved.
Does BOB actually want to see this problem resolved? Ok, so a useful plurality of BOB management sees the problem, but there is no consensus that it’s a problem — maybe they don’t want extra process or scale, maybe they think it will happen organically, or they’re just busy and don’t want a new initiative. Whatever they reason, they don’t care. Even if they want to care, they can’t manage to really care. So it doesn’t happen.
Does BOB management see their role in the creation or ongoing care and feeding of the problem? If thinking around the BOB general managers meeting is that there is a problem that just arose mysteriously out of the ether and is an unsolvable mystery, then the outcome is certain: nothing will happen. Problems are created – and solved – by people, and this is what management exists to do. To solve the thorniest problems, management must be willing to recognize their own part in the creation of the problem and course correct. If they’re unwilling to change how they manage the business, then how the business is managed will not change.
Can BOB figure out a plan to solve the problem? Imagine BOB management agrees the problem exists, needs to be solved, and recognizes their part in the creation of the problem. They know they need to change course, but can’t figure out how to chart a new one. If Bob can’t figure out what to do about things, they’re not to get better.
Can BOB successfully execute the plan to solve the problem? The final step: Can they stop managing how they’ve been managing, successfully change course, and go in a new direction without stumbling or turning back around? This may take some time to prove out, and they may find they need to change course again. That’s normal and expected. Or should be.

Knowing where you and your company are at in the five steps is key to successfully navigating organizational change, and that’s what keeps me coming back to Roy’s piece, time and again.

OK, great, now what am I supposed to do with this?

If you’re a leader at BOB, understanding where you’re at on that scale – and being honest with yourself about it – is going to be pretty key to the success of any initiative you’re undertaking. The more important the change, the more important it is to understand where you’re at.

And if you’re a leader thinking of joining BOB, you need to understand where they’re at, too. Worse, you need to try to separate where they think they are at from where they are really at, because the problem may not be seen the same way across the management team. See Levels 1 and 2, for example. Plenty of great leaders have joined companies both large and small and then found out the difference between an organization that truly wants to change versus an organization that wants to feel like it is changing.

But here’s the thing: recognizing the levels is a great tool for overcoming them. And just as Bob successfully made it through in Roy’s original essay, BOB can, too.

A nonsensical AI-generated image I somehow liked for this, courtesy of hotpot.ai

Quicksand meetings

2024-02-19T00:00:00Z

Lots of people dislike meetings, with good reason: Meetings interrupt. They take time. They steal focus.†

For managers, though, meetings are a key part of the job. It’s how they brainstorm, balance efforts, build alignment, and broadcast knowledge. It’s how things get done when you’re a manager.

Which makes it especially infuriating when managers schedule meetings that do just the opposite. Meetings that make it harder to get things done. Meetings that bring the work to a painful crawl. Meetings that cause more confusion and angst than they solve. In other words… Quicksand Meetings.

As a manager, you're trying to build momentum, clarity, and team morale. If you’re scheduling these meetings, you aren’t just creating problems for your team, you’re failing at those fundamentals of management, and you’re blunting your own impact and delivery. Become a better manager: schedule better meetings.

Take a look at the meetings you’re scheduling. Are they quicksand meetings? What would the folks attending them say? If you feel like you might have a meeting that matches one of these types, you probably do.

You try to fight back, but the harder you fight, the deeper you sink. Until you can't move... you can't breathe... because you're in over your head. Like quicksand. -- Keanu Reeves

Five types of Quicksand Meetings you don't want to be scheduling

The Eternal Standing Meeting

These are the meetings that turn up on calendars with regularity whether they are needed or not, forever. This isn’t a daily standup, it’s the ordeal created by the manager who says “I want us to get together so we can coordinate our efforts” completely ignoring that the folks on the team are already effectively coordinating efforts on Slack or Jira or any of the many other tools they have at their fingertips to asynchronously coordinate efforts.

And of course The Eternal Standing Meeting is usually scheduled at some terrible time “that was the only time everyone was available” like 7:30 a.m. every day and has no agenda or action items.

So everyone dutifully schleps themselves to the meeting, as requested, and pretends to pay attention while their mind wanders to a more productive use of their time.

At best the Eternal Standing Meeting duplicates coordination and communication that’s already happening. At worst, it’s a purely ego-driven exercise scheduled by managers who feel the need to center everything around themselves. Even if it impacts the work.

Possibly the most egregious example of the Eternal Standing Meeting is the hour-long daily standup. Nothing says “agile” like stretching what’s supposed to be a quick 5-10 minute meeting into a daily slog through minutiae. People only have about eight hours a day to get work done and you want to take 1/8 of that to talk about what’s happened since yesterday? It’s downright disrespectful of your own team.

The Fire Drill

The Fire Drill looks a lot like an emergency meeting, but then you find out that either the emergency isn’t really an emergency at all, it was just normal operations. You can often spot The Fire Drill because there is no context or information about the “emergency” in the meeting invite, only an urgent “we have to talk about this.”

Usually, everyone even remotely involved with the emergency is invited, but because there is no shared plan or context, people tend to wander aimlessly, hoping someone attending knows what's going on.

If you find yourself regularly scheduling Fire Drill meetings, you should first step back and ask why your team has so many fires, and why you don’t have effective fire suppression systems in place? Well run teams rarely have fires. They have plans. They have processes. They have it under control.

In the atypical cases where there truly is a fire, the lack of context fuels the fire. When everything is burning, effective communication is crucial. A contextless meeting isn’t that.

The Big Room

The Big Room meeting happens when a manager invites everyone even tangentially related to a topic and then invites more folks, just in case, whether they have anything to contribute or not.

A core handful of people who are invested in the topic will be at the center of the meeting, while everyone else is checked out, multi-tasking, or occasionally wandering into the conversation with non sequiturs.

In the old office days, everyone huddled into a standing-room-only conference room. In the modern remote era it’s more comfortable, but also much easier for the attendees to surreptitiously check their phone for the duration.

As a manager, it’s easy to think that inviting everyone is a good way to share context and communicate, but that’s wrong. But what you’re really doing is stealing focus and exacerbating Zoom Fatigue.

The most productive meetings have fewer than eight people (really) and you can communicate the results of the meeting to the larger group more effectively after the meeting, when you’ve had time to hone the communication.

The Chain Meeting

The Chain meeting is when you schedule an endless series of meetings that just circle back around to the same predictable places. There’s no decision-making, no consensus, just going ‘round and ‘round, ‘round and ‘round. If you find yourself scheduling your third meeting on a given topic and there’s been no real movement since the first meeting, you may be scheduling a Chain Meeting.

The good news is you can break the chain, starting now. Define the actions to be taken and a timeline for them. Know who the Directly Responsible Individual is for each item. Move things forward, not in circles.

The Marathon Meeting

The marathon should never happen, but it does, usually at the worst possible time: when the team is already behind and stressed. That’s when someone will have the bright idea to schedule 20 hours of calls straight through two days “so we can all go over all the requirements together.”

Of course it doesn’t work and people check out. That’s not how people’s brains work, it’s not how agile works, and it’s not how remote teams work. But people still try it.

If you find yourself even considering a Marathon Meeting, ask yourself this: How has it come to this? How has the work and the communication about the work broken down so completely that the only apparent solution is to stuff everyone in a room until they give up and cry “uncle”?

And then consider the cost of the Marathon, with all those highly paid people, not doing their regular jobs.

If neither of those things give you pause, you may not actually be a manager.

Five steps to avoid Quicksand Meetings:

All of these Quicksand Meetings share a few common traits: A lack of input, a lack of output, and a lack of ownership among the participants.

Does this meeting have a clear and actionable agenda? Has everyone seen it, along with any supporting materials they need to digest before the meeting? Give everyone a chance to do their homework and develop informed opinions before the meeting instead of shooting from the hip. You can still give a Bezos-style moment of silence at the start of the meeting to review the materials, but at least give folks a chance to get up to speed before the meeting. Before we leave the meeting, what actions are we taking on those agenda items? What are our next steps? Who’s doing it, and when? You should know. If you can’t name the action items and a person handling each of them, that’s a problem. You’re not done yet. Am I inviting the right people? And the right number of people? Curate your guest list like it’s a wedding dinner and each guest costs you 100 bucks a plate. Find the people who want to contribute and are prepared to do so. Leave everyone else alone. They’ll be glad you did, because they have other things to do. Communicate the outcome of the meeting. Do this for the benefit of those who weren’t in the meeting, but also to reinforce the understanding of the folks who were in the meeting. You may feel like you don’t have enough time. You do. Especially if it helps you avoid another meeting on the topic. Track your meeting load. Do it for yourself. Do it for your team. On a personal level this is built into Google Calendar. At the team level, you may want to consider something like Clockwise to track your teams’ bandwidth, and think about what a healthy bandwidth number really looks like, both for delivery, and for a healthy team.

As managers, we sometimes hear “the meeting is the work” but that’s not quite right. Meetings are in the middle of the work. To make them useful, you as a manager have to put in the work to prepare for them (and to prepare others for them) and then you have to follow up on both the actions and communications afterwards. That’s the work.

Good meetings are a quick and effective way for a group to collectively get from Point A to Point B. To do so, you should go in with a clear and shared understanding of Point A. During the meeting, you should identify Point B, what it will take to get there, and who is doing each of those things.

That seems like a lot for my little meeting

Does every meeting need all of that structure? No. For some meetings, particularly 1:1s or team-building/conversational type meetings, that much structure can get in the way or even be counterproductive. Maybe you need a partial agenda. Maybe you don’t need an agenda at all. Feel it out, and see what the other folks in the meeting think.

But if you find yourself invited to a Getting Things Done meeting, be sure things are getting done.

Time is the one resource that does not and cannot scale. Don’t waste it.

Hat tips

Kevin Hoffman’s “Meeting Design” is highly recommended. Kevin’s a righteous dude.
The 1944 CIA Simple Sabotage Field Manual is a good primer on how plan bad meetings, too. Thanks to Bill Hunt for a timely reminder of it.
And many thanks to Mark Headd and Elizabeth Ayers for challenging me to think harder about all of this.

†”There is no shortage of think-pieces about bad meetings”, he says, as he adds another to the pile.

Know your (documentation) audience

2024-03-01T00:00:00Z

Many years ago, armed with little more than a crude word processor and a take-on-the-world attitude, I embarked on a quest to become A Great Journalist. Day after day I fell bleary-eyed into early-morning classes, seeking knowledge. My words were going to make a difference.

In the end, I only became a Middling Journalist, but I did manage to pick up a few insights and aphorisms that have proven useful since. Few are as useful and true (if clichéd) as this:

Know your audience

My journalism days are long past, but I continue to find applications for that shopworn slogan. It's hugely applicable in design, of course, but also product management and engineering. And nowhere in engineering is it more applicable than when it comes to writing technical documentation.

Every day, engineering teams everywhere bicker endlessly about where to put their docs: Do we need a developer portal? Should they all be in Confluence? Do we need a Wiki?

They endlessly seek the Single Source of Truth, writing and re-writing docs hoping to create the one true version of their technical docs. But here’s the real truth: for most engineering teams and technical projects there will never be a Single Source of Truth because there is no single group seeking truth.

You have to know your audience, so start with the simple questions: Who will read these docs? Why? What do they hope to learn?

Just thinking about the audience for your documentation will put you ahead of most engineering teams, because most engineering teams don’t really understand – or completely misunderstand – the audience for their technical docs. Even fewer understand that they almost definitely have more than one audience for their documentation.

Nearly every engineering project will have at least two different audiences for their documentation.

At least two audiences. Probably three or four. Maybe more.

Know your audience(s)

Each of the audiences for your docs have divergent needs and desires. Without understanding that, your documentation will always be bloated, messy, and hard to understand. You don't know your audiences, so you’re not giving them what they need. If you’re like most teams, you’ll either give up and leave everything under-documented, or you’ll shotgun out ever-larger heaping piles of docs, few of which will ever be read, let alone usable to their audience.

Each of your audience needs documentation at a different fidelity, in a different location, to meet different needs. Your Single Source of Truth is wasting all their time. And yours.

You need to write the right documentation, for the right audience, in the right place. And that’s not a one-time thing. So who are the audiences? Allow me to pull back the curtain and shine a spotlight...

1. Engineers in the codebase

This is probably you. And your team. And your future teammates. You are the folks reading and writing the code, actively developing it.

What you want (what you really, really, want) is documentation adjacency. You want the docs to be close to what you're reading or writing spatially, not in some far-off wiki, but also focused cognitively to the work at hand. In other words, you don't want or need a birds-eye view of the system, you need to understand this function, right here. And that's enough.

So it makes sense that these docs should live in the code, or as close as possible to the code it is talking about. I mean, you can't generally put comments in JSON, but you can, and should, put any docs you need explaining the JSON as near to it as possible, probably in the functions creating or consuming the JSON.

Also remember that you and your team will likely read the code far more than you will write new code, so document accordingly.

Adjacency to code: high
Granularity: high
System-level understanding: low
Explanation of benefits: low

2. Engineers leveraging the codebase

This could be teams building on your platform, or consuming your API, or leveraging your open source project, or a million other things. Whatever they're doing, they have their own code to worry about, but for some miraculous, wondrous reason they want to use yours too. You should be flattered, and you should take good care of them by understanding and meeting their needs.

But if it's all engineers, what do they want that's different than what you and your team wants? A higher-level system view. They probably don't care about the individual functions and they almost definitely have no interest in reading your code to understand it. They want things like:

how-to instructions to implement and get it running
Understanding of how to interface with it
Gotchas they should watch out for
Code examples and snippets to show how things work
Clear and honest documentation of limitations. If it's not going to do [thing] but they really need [thing] let's just get that out of the way up-front.

These folks don't want their docs in your code, because they don't want to read the code, but they probably want it pretty adjacent to wherever they go to get your code. Most times, that's probably the github repo, or someplace close to it. This is where you want to document the higher-level technical functions and APIs, and how engineers are expected to consume and use your codebase. It’s where documentation generators – SwaggerUI, Doxygen, Swimm, etc – may be most helpful.

Adjacency to code: medium
Granularity: medium-low
System-level understanding: medium-high
Explanation of benefits: medium

3. People understanding the codebase at a high level

This is most likely to be stakeholders, prospective partners or customers, your product manager, a technical writer or even your marketing department. Whoever it is, they have a healthy interest in your codebase, but they’re more interested in what it does, rather than how it does it. Many times, they’re seeking enough understanding that they can then explain it to their own audience.

This group may be looking at the docs pretty far removed from the actual codebase, and that's OK. In fact, for this group, Confluence or some other system closer to where they work can make a lot of sense.

Adjacency to code: low
Granularity: low
System-level understanding: high
Explanation of benefits: medium-high

4. People using the product built on the codebase

These could be your most valuable audience, but too often they're ignored by engineering completely and simply handed off to the marketing department.

This group has very little interest in the codebase. If they’re looking at it at all, it’s probably because they accidentally wandered into the Github repo from a link added by someone who didn’t understand the audience he was speaking to.

What this group wants to know is simple: can it solve their problem? As an engineer, you offload these conversations to another department at your peril: You know better than they do what your code can and can't do, so you are better equipped to take at least the first pass at documenting it.

Talk about the benefits with honesty and without hype. Someone will inevitably add additional hype downstream of your efforts. Before it gets there, though, you can have a real conversation about why you created the thing you created, who you created it for, and what it can do to make their lives better. The how is for another audience.

Adjacency to code: very low
Granularity: very low
System-level understanding: medium
Explanation of benefits: high

Putting it all together

Writing docs for all these audiences sounds like a lot of work, but in practice it could lead to writing fewer docs that are more effective. If the docs aren't meeting the needs of the intended audience, and meeting them where they are, then throw those docs out and never update them again.

And the docs you are investing time in will have more clear value. Your team is happier. Your stakeholders and users are happier. Your product is more successful because the folks using it are happier and more able to solve their problems. For each audience, you’re focusing on their needs, and not weighing them down with extraneous baggage. They appreciate that.

In many cases you'll be moving the docs someplace more adjacent to the codebase, if not within it, which means keeping them up to date gets a lot easier: you update them when you change the code that's right there, rather than updating some far-flung wiki no one remembers to read.

Know your audience.

To help visualize all this, here’s a carefully crafted high-fidelity rendering I created:

Here's a finely hand-crafted scatterplot with some squiggly dots intended to represent some of your audiences and their needs.

With my thanks to Stacy Holmstedt, Jeff Triplett, Jennifer Wadella, Josh Chessman and others who helped me bounce these ideas around. If you’re interested, Daniele Procida built a framework on some similar ideas awhile back. Check it out at https://diataxis.fr/

So you don't want to be a manager

2024-03-07T00:00:00Z

I’ve heard it a thousand times from a thousand engineers: “I don’t want to be a manager.” A lot of senior engineers think this, but I’m not sure many of them understand what it will mean to them and their career. Here it is:

This will be a long, hard and lonely journey.

Your career progression will slow to a crawl. You'll watch your peers move up in the company before you. You'll wonder why. There are a few good reasons, and they're all hard to hear.

1. Your organization does not need very many senior (Staff+ level) ICs

Most teams are fairly autonomous. They have reasonably good to very good engineers on them who understand the systems they use. They have managers who are talking to one another, filling in the blanks. There's only so much need for a Super Engineer who knows how everything across teams works. Most of that work is already getting done.

When you have one, it can be hard to find Super Engineer-level work for them to do, and it's really easy for management to start wondering what Super Engineer is doing to justify their very expensive salary.

So there's not a lot of need for really senior pure ICs, not a lot of demand for them, and not a lot of seats for them. Take a look around: most likely your org has somewhere around five engineering managers for every IC-track Principal Engineer. That's not to say you can't do IC work. It's to say that if you only want to do IC work, the demand can be thin. There's almost always demand for another team lead.

If you want one of those Principal seats, you're going to have to show a lot of value, and you're still likely to be stuck because there just isn't a seat open. Meanwhile, the folks on the management track have a much easier time finding openings. People are messy and everyone mostly agrees they need managing.

2. It's really hard to show impact as a very senior IC

From here on out, your career progression is mostly about creating larger and larger impact zones. As an IC it can be be hard to even create opportunities for impact, let alone have people recognize it. Let me break it down:

As a Senior Software Engineer, you've mastered at least one and probably more than one of the systems your teams use. That's awesome. Your impact zone is that system.

If you become a Team Lead, in addition to caring for your team, you'll also be building relationships beyond the borders of your team. Similarly, as a Staff Software Engineer (on an IC track) you'll be looking at the systems beyond the borders of your team. That's the impact zone at this level: one team, looking to create impact beyond the borders of that team.

And so it goes: as a Principal Engineer you'll be expected to have mastered most systems and have an impact zone beyond the walls of the department. Or even outside of the organization. At some point, you'll be expected to uncover whole new lines of work or create mass efficiencies across the organization. That's hard.

3. You'll be mostly alone

This ties back to the first point, but it's worth calling out separately. If you take this path, you'll be largely on your own. Especially as you go higher there are fewer and fewer people on the path with you. You'll have fewer people to bounce technical ideas off of and you'll have to figure more out by yourself.

But I don't want to be a manager, you say.

Hey I get it. You've got to do what feels right for you, and going into management can just feel wrong for a lot of engineers. You're not alone. You're not even uncommon. People are messy and complicated and they make funny noises and they want things. Ick.

And it feels like you're leaving behind everything you're good at. You are. You're taking on an all-new thing and the odds are that you'll probably be terrible at it at first. Most new managers are, until you figure it out. The world is full of lousy managers and new managers tend to swell those numbers. Especially if they don't have a great manager themselves to guide them.

That's a bitter pill when you've fought to reach a stage in your career where you're respected and are just beginning to feel like an expert. It’s even harder if you’re prone to feelings of Imposter Syndrome.

This is one reason why a lot of engineers swing back and forth on the pendulum.

I get it. I do.

I completely understand why you feel the way you do. People who follow and succeed on an IC path can be transformative. They can make highly technical (and potentially highly profitable) things happen that no one else can even see as possibilities.

Senior-level ICs can wander from team to team making the hardest problems just disappear. They have real, visceral, quantifiable impact. There’s no denying the appeal in that.

And they're building on their strengths rather than riding the "I'm not sure I'm good at any of this" rollercoaster that leaves pits in the stomach of new managers.

But at the same time, some folks find that squishy people-problems are intricate and fascinating in a way that technical problems rarely are, and they find great satisfaction in that.

There are also a lot of people who find that becoming a manager unleashes their super-powers. These are the folks who may have been under-recognized and under-valued throughout their career because they excel at glue work and were seen as "not technical enough". Now, as a manager, those skills they've honed are suddenly incredibly valuable. Critical, even. They have, finally, met their moment.

After all of that, you still don't want to manage?

Good. You do what feels right for you, just do it with open eyes. For some folks, even knowing all of this, the IC track still feels right. If that’s you, awesome. Go forth and do great things. I just want you to know what you're getting into. And that you can change paths if you change your mind. Good luck!

Edited later 3/7 to clarify a few points people had raised. Thank you, people!

AI is boring and stupid and maybe that's OK

2024-03-11T00:00:00Z

We’re now just a bit over two years into the AI revolution. The chorus of hype and promises — both empty and real — remains deafening. The capabilities of AI increase every day. Yet right now, the most impressive thing about AI may be how quickly we’ve trained our primitive monkey brains to recognize how incredibly boring it is.

In months, really, we’ve retrained our brains. We've gone from being utterly dazzled by the magic of AI to seeing the machine behind the curtain, moving the levers. Not long ago we watched incredulously as AI conjured credible art out of thin air, held lengthy conversations with us on the fly, and generated new lyrics for Taylor Swift songs anytime we liked. Then, after a moment of magic, we started to shrug.

We learned in an astonishingly short time to recognize AI-generated content for what it is: Boring. Trite. Been there, done that, got the AI-generated T-shirt.

Inspiring, isn't it?

AI as a capability may be fascinating, but the output of it is nearly always dull and plodding. Recognizable as the work of a machine and marked by predictability and sameness. The AI-generated art proliferating across blog posts and the pages of LinkedIn Thought Leaders has already become a cliché. When we see someone pass off AI-generated text as their own, we know.

We know.

We’ve learned to see it, and just as we can’t help but see the green screen effect in an old sci-fi movie, we’ll only get better at spotting it, until eventually it's all we can see.

Boring by design

AI is built to be boring. That’s literally how it works: it predicts the most likely next word or pixel, based on the gazillion words and pixels fed to it. The problem is you, you’ve likely seen some version of the words and pixels fed to it before. Not every permutation, but enough to recognize the lack of originality.

And so it goes with the most visible use cases for AI today: We see AI-generated art and reject both the processed sameness of it as quickly as we recoil from the six-fingered uncanny valley.

We gloss over AI-generated text the same as we’ve learned to gloss over text that’s clearly overly optimized for SEO. Whether written by machines or for machines, our human brains want text written for humans, quirks and non-sequiturs and all. We want humor and humanity and something that makes us think in a way we haven’t thought before.

Creativity doesn’t exist without unpredictability. Good doesn’t exist with humanity. Not yet at least.

So, in a remarkably short time we’ve trained ourselves to see the machines working, and we recognize their work is largely... boring.

And yet, this is not a problem for AI. Or for people. Because a lot of what we do every day really is boring. Repetitive. Predictable. The sort of thing the machines literally trained on.

Boring can be useful

The world is full of things that exist because of a need to fulfill some requirement, not because they need to bring us joy. Sometimes we just need to get something done in order to get to something more important to us.

We write an awful lot of boilerplate and scaffolding on our way to something else, and then we write a lot of other things just to check a box. Boilerplate code. Boilerplate legal documents. Boilerplate grants and guidance and RFPs and SOWs and a whole alphabet soup of other documents and filings and records and reports.

We don’t always need these things to be good, we just need them to be done. This is where AI can really shine. It’s great at creating all that boilerplate and scaffolding, and then it can just as easily turn around and consume it all and spit out a nice, concise summary.

If we really over-achieve we can build a future where mountains of content aren't written or read by humans much at all. And maybe that’s not a bad thing. I mean, a lot of this stuff was never all that human-centered or human-readable to begin with.

The worrisome part is that nobody reads this stuff now, so who's going to read it and catch errors in the future? Any editor (or coder) will tell you: it’s easy to gloss over errors when something is already written.

So what if errors sneak in? AI can catch those, too.

Sure. Maybe. But will they catch them before real people are impacted? I don't think so. We know real people are impacted already, starting with the people who created the works AI is regurgitating. But as more and more AI-generated text creeps into more places – especially highly regulated places – what will it bring along for the ride?

This is especially worrisome in my field – government technology – where what's written determines which people receive needed benefits. Which Veterans get services. Which mothers are able to feed their children today. Which small businesses will survive thanks to a government loan. Literally, an entire world hinges on fine text and how it's read and interpreted. This is the kind of text AI excels at generating and we are terrible at reading.

My very smart friend Mark Headd recently wrote up some pretty smart use cases for AI and LLMs in government. Bill Hunt, another very smart friend also working in government, has a pretty strong opinion that today’s AI models aren’t ready. I think it’s possible that they’re both right.

There's an air of inevitability to generative AI – a vibrating sense of a genie in the air, refusing to go back into the bottle, sending a siren call to both those eager to summon and those fearful of what comes next.

What comes next is happening now, and a lot of it is happening in highly regulated and highly senstive spaces. Government systems are using AI to detect fraud and waste, to help agencies with regulatory compliance and, undoubtedly, a lot of other things. With a lot of questions about what happens when there are false positives, or false negatives.

AI generated content may be boring and trite, but that doesn't mean people aren't finding it incredibly useful, today, right now. And many of the most touted, most exciting use cases remain largely on the horizon.

We can't wait to reach that horizon before we start figuring out how to handle editorial control, quality checking, rules compliance and a host of other factors for anything AI-generated.

We’re going to have to find a way to ensure that AI is producing something like what human intelligence would have produced and that it is not introducing a bunch of errors. Getting AI to generate boilerplate is the easy part. Figuring out how we ensure that it’s correct will be the bear we have to wrestle.

This is not the first time we've had this problem.

The assembly line

True fact: The precursor to modern assembly lines – arguably the first assembly lines – could be found in 19th century meatpacking plants. There you'd find overhead trolleys moving heavy carcasses from worker to worker for processing. At the time "processing" generally meant large knives and bone saws, so conditions were dire. Defects and accidents were largely ignored – even though they could be deadly.

When automotive assembly lines in the early 20th century spurred a manufacturing revolution across industries, defects and errors still abounded, especially when plant owners made the the machines run faster to drive greater productivity. They got the idea from English textile companies, who had done for years with their looms – much to the horror of Luddites, who really just wanted a living wage and respect for workers. But we were talking about errors....

It wasn't until well into the 20th century that manufacturers really began to master rigorous multi-stage, multi-faceted quality control. Even with huge advancements in the field, quality in many industries has remained spotty and sporadic.

And that was when inspectors and testers only had to move at the speed of the line, which was limited at each step by what one person could do. Today, with AI we've automated the creation of nonsense at mass scale. Our traditional quality control checks don't match and won't scale.

We already know that AI-generated code lowers quality. We've discovered that it increases racial bias in hiring. Microsoft's AI reportedly generates violent sexual images while Google had to stop humans from generating images of other humans after tripping over themselves trying to correct AI stereotypes and bias. Across the industry, people are calling out failures to limit bias, misinformation and controversial content. The hazard of mimicking human content is that humans say some pretty messed up stuff.

So given both the mediocrity of generated text and the high likelihood of damaging errors in generated content, how do we ensure safety and validity in highly regulated services where when compliance, correctness and contractual obligations are on the line? Who's going to check this stuff?

I don’t think we can trust humans to be the answer. Even if they want to ensure accuracy and have a strong vested interest, I don't think they'll be able to keep up with fact-checking and error-checking all the content AI can generate.

So of course the answer is to have the AI check itself. Just like grizzled veteran editors taught newcomers to read stories from bottom to top to break the brain's flow and catch errors, we'll think up creative ways to make AI better at catching it's own mistakes. But of course each layer of AI cleverness creates another layer of AI to check. It a hall of mirrors. A matryoshka. A hall of mirrors endlessly reflecting matryoshkas.

For now, we find ourselves hacking through an ever-deepening forest of generated content, hoping we can spot the bear lurking in the forest before it mauls us. We're not good at this, and we're not going to be good at this. That forest of AI-generated content is boring as hell. And yet, somehow, we will find a path through it. It will be OK.

Unless we use up all the electricity in the world first. In the meantime, here's a picture of Joe Biden and Donald Trump enjoying some quality time together.

Reality is the only word in the English language that should always be used in quotes.

11ty Linkrolls

2024-03-13T00:00:00Z

One of the things I've always loved about blogs were the linkrolls... that candy trail to more and more interesting things scattered around the web. I love to see folks sharing the interesting things they find. Social media is built on that sort of sharing, but they've also commoditized it and gamified it beyond recognition, and there's no persistence to it, either. I wanted an old-fashioned linkroll for myself.

Surely, I thought, this must be a paved cowpath in the Eleventy world, so I asked on Mastodon:

And I learned that yes, it has been done (and done well), but how to do it is less clear. in particular Nicolas Hoizey had a very nice version, and had written up part of it. In the interest of completeness (and so I can remember how I did it), here are all the steps. I should also note that Nicolas' implementation is way, way more sophisticated and complex than mine, and that his 11ty codebase is chock full of interesting things I'll probably emulate later. For now, for this linkroll, this is the cavedweller version. We're digging for fire here.

Prepare the bookmarklet

Install the bookmarklet NPM package with npm install bookmarklet or, if you're like me and you have some sort of NPM path issue you don't want to track down, shake your head and make it a global install: npm install -g bookmarklet
Following the link from Nicolas' site, I grabbed his bookmarklet code and put it in the same location on my site: /assets/js/bookmarklets/
In the bookmarklet script, look for newFileUrl and change the Github address to your own. I also modified it to automatically prompt for tags after getting really confused about why my pages didn't show up in any collections. You can see my version in Github.
Build the bookmarklet with bookmarklet --demo assets/js/bookmarklets/new-link.js src/tools/bookmarklets/new-link.html. Note that the last half of that command is the destination. In my case, I had to create a directory or two before I could get the output file there.
Fire up your local site with npm start and navigate to http://localhost:8080/tools/bookmarklets/new-link/. You should see your bookmarklet and be able to drag it to your bookmarks bar.
This is a good time to test it. Navigate to any page and click the bookmarklet. You should see prompts for the page title and a slugified (URL-safe) version of the title. If you're using my version, you should also get a prompt for tags. Click "OK" through the prmpts and you should get redirected to github, where you should see a draft of a new page.

Creating new entries for the linkroll

Whenever you click the bookmarklet it will create a new page in Github. At that point, you still need to save and commit the changes to create the new entry. I don't know if this part could be automated, and I didn't look into it because I thought it was a useful final step to ensure that the entry looked correct and an additional point to add any last-minute edits.

Anything in the page you create here should be available to your site downstream, so you very well may want to add additional information. By default it attempts to grab and excerpt from the page, but you can also add your own thoughts.

Showing the entries

This is where things went sideways for me and the simple things got hard. I got pretty confused about why my new content didn't show up, and why I didn't have a "links" collection.

It turned out that the original bookmarklet didn't add any tags -- I'm guessing Nicolas adds them himself -- and without them, the pages didn't appear in any collection and the collection wasn't created. Once I figured that out, things got simpler.

To create a links page, I pretty much copied what Nicolas had done for his archives, although in a pretty dumbed-down version.

I grabbed Nicolas' link index page and made my own version.
That index page relies on the linkcard macro, which in turn relies on the card and meta macros, all of which I grabbed from Nicolas and then stripped down. I admit macros are a part of 11ty I'm not familiar with, so it's very possible this part could be simpler and/or more elegant.
Fire up the local version again, if it's not already running. You should see a page with the link you created earlier (although you may need to git pull to bring it down to your local build). If not, start debugging.

I also created a simple sidebar for my index page, which was considerably less involved:

    <ul class="linkroll">
        {% for link in collections.links %}<li>
            <a href="{{ link.url }}">{{ link.data.title }}</a>
            {{ link.content | safe }}
        </li>{% endfor %}
    </ul>

So, that's how I did it.

My to-do list from here

Make saving a new entry trigger a Netlify build. Right now it doesn't appear to. I imagine there's a Github action or something to do it, I just haven't figured it out yet.
Possibly related to the above, or causing the entry to not show up on deployment, but I introduced a defect when adding multiple links. They're becoming a single string, so they don't get added to collection properly. I'll have to sort that out.
Think about how I might introduce images. Nicolas appears to use thumb.io to get screenshots. I'm wondering about leveraging og:image tags where they're found
Nicolas really does have a lot of interesting ideas in his repo, and I think I'm likely to incorporate more of them.

The handcycle

2024-03-28T00:00:00Z

This is one of those projects where I wish I'd kept better notes and photos, because it was pretty fascinating to me....

In spring 2001 a friend learned I'd been renovating old bikes and asked if I'd look at his daughter's bike. His daughter has some issues with mobility, so the bike in question was a handcycle. I'd never heard of a handcycle, let alone put a wrench to one, but was I going to let that stop me? No, I was not.

When it came to me, it had been sitting in the back corner of a warehouse for some time, and that time had not been good it it. Aside from a thick coating of dust, it appeared someone may have backed a forklift into the front wheel. In addition, chemicals in the air at the factory had attacked the metal parts.

The starting point for this project. Dirty and neglected, but sound.

On the other hand, the paint was still good and it was sound and not overly rusty. It would clean up.

Before I tore into it, I took a minute to familiarize myself with handcycles. Essentially they're sort of a trike, using wheelchair back wheels, coupled with a combination steerer/crankset operated by the rider's hands to provide forward propulsion. So there are lots of off-the-shelf bike parts coupled with off-the-shelf wheelchair parts, all used in interesting new ways and mixed in with some bespoke custom stuff to make it all work.

The crank is a pretty standard 110BCD square-taper triple crank. Looked a bit like a Sugino to me, but it wasn't marked. A very tiny chainring is bolted to the inner mounting point. You can also make out the vertically-mounted brake lever, which is set up to act as a parking brake.

For the most part, this was a straightforward refurbishment, with a few twists. All the normal stuff you'd buy for a bike refurb was just a bit different. For example, the tires were wheelchair tires, which I had to track down a good source to find. Eventually I discoverd sportaid.com, who have everything one could want for a high-performance wheelchair, including some nice tires.

One thing I learned: wheelchair tires run at very high pressure and they are very hard to seat on the rim. I think I broke a half-dozen tire irons.

The chain was also a bit quirky. Because of the length of travel from the hand cranks to the front wheel, I had to buy two chains and merge them together.

The front wheel had a big flat problem.

The front wheel had taken a pretty bad hit, and I didn't trust the rim to be solid anymore. I lucked out and found a New Old Stock Sun CR18 rim that matched the stock rims nearly perfectly. Score! This was before I learned to lace rims myself, though, so I had a local shop lace swap over the stock Shimano internal-geared hub to the new rim. They did a great job.

Speaking of that Shimano hub, they're not for the faint of heart, even for someone like myself who's experienced with Sturmey-Archer 3-speed hugs. Luckily I just need to re-lube it and it and give a good cleaning. It worked beautifully.

Reassembly. That big bracket on the fork is for two chain idler pulleys. The chain is that long.

A lot of the work was pretty normal, though: disassemble, clean, lube, re-assemble. In spite of the surface corrosion the bike cleaned up well and as it came back together it looked nearly like new.

Finished!

So what's it like to ride? It's work. The 8-speed hub and small chainring help, but even if you enjoy cycling, this is a whole different set of muscles. But it's also a lot of fun.

Most important, the owner loved having her bike back so she could go for a ride whenever she wanted, on her own terms.

And isn't that what it's all about?

About this site

2024-04-07T00:00:00Z

April 8

I skipped some small updates over the past few weeks, but today sees the launch of some fairly major typography and hero image changes.

Mar 15

I've recently added a linkroll and links page, along with a page about me. I'm thinking a bit about the about | ideas |now model but don't honestly know if I want to keep up with updating all those pages. Seems like a lot.

I've also been making CSS tweaks here and there. I need to take a harder look at the CSS. It is currently broken on small screens, I'm not sure my color choices are accessbible, and I don't love the way it's organized and builds.

Feb 22

I've needed to fix the site navigation for awhile now, and finally did. I used the simple 11ty Navigation Plugin and it was so easy it made me a bit embarrassed that I hadn't fixed it already.

Feb 7

I've added a lot more content this week as I consolidate various things I've had on other websites and bring it all here. That means my Smart Camper content is here now and I'll be retiring smartercamper.com, and I've started bringing over a bunch of the bike content from re-cycled.net. I'll be retiring that one, too.

I've also pulled in the Giant List of Questions for Prospective Employers. I'm experimenting with embedding that here as a Github submodule. We'll see how well it works.

And I added a bunch of photos and thumbnails.

Jan 30, 2024

As I begin to diverge from the perfectly nice 11ty Netlify jumpstart template, I've changed the main logo image and theme colors. Those who have known me for awhile will recognize the horseshoe isn't just a nod to this site's name, it's also the same horseshoe found on Gretsch guitars, in particular the Gretsch 6120 Chet Atkins. I created the Gretsch Pages in 1995 and over time it became the leading resource and community for Gretsch guitar owners. After 25 years I retired, but not without some regrets. It was a huge part of my life for a very long time. Just seemed right to have a little homage here.

We're doing it live

I'm Carter Baxter. I like to tinker with things. You can read more about me on Linkedin, on Github, or on Mastodon.

This site is a little clearinghouse for various experiments and projects I've taken on and tinkered with. Because it's all about the projects, we'll treat the site as a project, too, and build it out live.

We're starting from the 11ty Netlify jumpstart template and going from there. If I don't abandon the project, it should be constantly changing. We'll see where it goes.

We're building it out in the open. Photo generated by hotpot.ai

On values

2024-04-08T00:00:00Z

One crisp spring morning in May 1969, a soft-spoken, mild-mannered 41-year-old sat down in front of the United States Senate Subcommittee on Communications and quietly took on the Nixon administration.

Nixon wanted to gut funding for public television and the Corporation for Public Broadcasting. In his eyes, and in the eyes of many conservatives at the time, public TV was an expensive government overreach, a waste of taxpayer dollars, and a hotbed of liberal and progressive indoctrination.

Against that backdrop, this subdued man spoke to the US Senate, delivering an impassioned and heartfelt case for the importance of television programming that nurtured, that led with empathy, and created smarter, more well-rounded people.

This was not a winning pitch for the Senate Subcommittee on Communications. The heartfelt plea was met with skepticism, the passion with derision. Arguments were skewered. Entreaties ignored.

This quiet man did not waver, though, and eventually enough of the committee — and enough of the public — saw things as he saw them. The votes were there, and no matter what Nixon wanted, public television funding would stay.

That is, of course, the story of how Fred Rogers took on the President of the United States, stood by his convictions, and saved public television — and “Mr Rogers Neighborhood” — for the next three decades.

Later the same year Rogers again stood up with quiet conviction against powerful forces when he invited Officer Clemmons — a black man — to soak his feet in a wading pool on a hot day. TV itself was almost completely segregated in 1969 — outside of comedy/variety shows, about the only diverse cast you’d find was on Rogers’ PBS neighbors on Sesame Street — and swimming pools across the country were still segregated. Racial tensions in general were running high. Yet here was Fred Rogers, dipping his toes in a pool with a Black man. His critics said it was inappropriate and divisive. Rogers did not care, and he did not falter.

Choices

The point here is not to extol the virtues of Fred Rogers. There were many, and plenty of folks have done a great job of talking about them. They’re right. No, the point here is to talk about what Rogers knowingly gave up in his unflinching commitment to his values.

He gave up a fortune in lucrative merchandising and merchandising deals in order to preserve the integrity and authenticity of his program over making a fortune in licensing and merchandising deals.

He weathered a lifetime of whisper campaigns full of baseless accusations and character assassinations, turning the other cheek to his detractors and leaving their foul rumors unaddressed. He acted as he believed, guided by the power of kindness, forgiveness and grace.

He struggled through his life with his own mental health, depression, and anxiety. He grappled with the weight of his work and buckled under the load of constant emotional labor, caring for so many others.

Fred Rogers understood this well: for everything we value — for anything we value — there is something else we are choosing not to value, whether we’re aware of it or not. There are trade-offs and compromises. So it is for all of us.

What we care about costs us.

If we value a quiet, simple life, we’re not optimizing for material possessions, or a rich and busy social schedule. We may be de-prioritizing connection and community, or wealth we could have pursued.

And if we optimize for connections and relationships or success and achievement, we may have a life full of cocktail mixers and lively conversation, but our personal lives are likely to be anything but quiet and simple.

These things aren’t binary. Most of us fumble along somewhere in the middle, without truly optimizing for any one particular thing, or we flip-flop between valuing one thing and then another.

Still, as we consider what we truly believe in and truly care about, there is also value in considering what we don’t, and why.

Which brings us to corporate values

Corporate values. Oh boy. Every company has them, and most of them are terrible. Superficial. Hypocritical. Hollow. You know it, I know it, most likely the corporation knows it, too.

Most corporations, just like most people, don’t really think through the choices they’re deprioritizing when they choose their values, which is how we get hollow and meaningless values.

There are endless empty lists of corporate values you can pick and choose from and have ready-made corporate values, without all the messy reflection, introspection, or thinking about the tradeoffs inherent in optimizing for any given value.

“Integrity,” for example, consistently tops the list of most common corporate core values. Companies tout their honesty, transparency, and desire to do the right thing, even when it's difficult or inconvenient. But integrity is inherently at odds with the true number one goal of nearly every corporation over the past 40 years or more: maximizing shareholder value.

It’s not even a matter of illegality or unethical behavior. True integrity means telling customers honestly that maybe your product isn’t the right product for them. It means standing behind a product even when doing so might be very, very costly. It means being transparent about those things that drive down shareholder value.

Fred Rogers made a choice to value integrity over a fortune he could have made. Few corporations would do the same, and many would argue that they shouldn’t, that corporations should optimize for profit over all else.

Google’s “Don’t be Evil” mantra remains one of the most famous corporate core values ever. In their 2004 IPO letter, Google founders Larry Page and Sergey Brin recognized the tradeoff inherent in the value, saying “We believe strongly that in the long term, we will be better served—as shareholders and in all other ways—by a company that does good things for the world even if we forgo some short term gains” (Emphasis mine).

Over time, however, it became clear that pursuing and following “Don’t be Evil” would mean giving up wildly profitable surveillance capitalism, anti-competitive behaviors, and discriminatory and retaliatory labor practices, among other problems. Google initially set a high bar, but in 2018 they dropped “Don’t be Evil” from their core values in favor of the more ambiguous and anodyne “Do the right thing”.

Corporate values tend to ring hollow because we can see the company clearly optimizing for something other than their stated value. Starbucks, for example, says it strives to “[Create] a Culture of Warmth and Belonging, where Everyone is Welcome” yet it installs hostile architecture, closes restrooms, and even removes or covers electrical outlets, all in an effort to deter people from staying too long in that warm space where everyone is welcome. And ask any union organizer how welcome they were in Starbucks’ culture of warmth and belonging.

Similarly, Amazon’s stated value of “Customer Obsession” appears increasingly at odds with an ever more frustrating slog through page after page full of junk products, many of which may be actually dangerous and harmful to those same customers Amazon claims to be obsessing over.

Can a profit-driven corporation manage to create values that ring true, understand the trade-offs, and follow them anyway? Sure. Patagonia is one great example. They’ve consistently sacrificed profit in favor of sustainability and fair labor practices. They’ve foregone traditional marketing in favor of authenticity and transparency. They’ve encouraged customers to consider waste and environmental impact, even if it meant fewer sales. Sounds a bit like Fred Rogers.

But most companies fail to live up to their stated values. In many cases, their values never meant much in the first place – they were probably put together by a small team from marketing or HR and never reflect the true organizational culture or interests of leadership.

Other times the company has the best intentions when they post their values, but they fall down when facing financial pressures and managers trying to make their numbers. In other words, the company wasn’t really willing to accept what they would give up for their values.

This I Believe

In 1951, right around the time Rogers was getting his degree in child psychology, legendary journalist Edward R. Murrow and the CBS radio network began airing a short, five-minute program called “This I Believe,” in which both famous people and people who weren’t famous at all would write essays about their values and what they believed in. The show became a cultural phenomenon in the 50s and has been revived multiple times since.

One could listen to famed science fiction writer Robert Heinlein talk about his belief in in the virtues of communities and “Our Noble, Essential Decency, Margaret Sanger’s belief that all children should be wanted before they are conceived, or Oscar and Esther Hirschmann, a New York City couple whose biggest claim to fame was being married to one another for 30 years, as they explained how they believed their love for one another was their key to loving and understanding their fellow citizens.

The appeal is clear and perennial: At its best “This I Believe” segments are not stories of people crowing about their beliefs or patting themselves on the back for their own empty platitudes. They are stories of people doing the work of examining what they believe with a sharp and analytical eye, successfully distilling down to the essence of their core beliefs, then showing the world their work.

We could use a bit more of that.

We can’t all be Fred Rogers, as individuals or as companies, unfailingly, forever following our convictions. We have foibles and missteps. Things go wrong.

Even if we recognize we may fall short, we can do better, as individuals and as companies, as we contemplate our values. We can do is think harder about what we truly believe in and what we’re willing to forgo to believe in those things. We can be transparent and honest with both ourselves and others about what those trade-offs look like to us, so that our values do not sound hollow and hypocritical.

Do the work. Show the work. Stand by the work.

This I believe.

We’ve got to make the damn websites work

2024-04-16T00:00:00Z

When leaded gasoline was introduced in the early 1920s, it was a real innovation. Every engine suddenly ran better, performed better and lasted longer. Consumers rushed to it, and for decades leaded gas was the gold standard. Then we learned more about the harmful effects of lead and lead pollution. By the mid-1960s we knew it was terrible stuff, dangerous to the public health, and still it wasn’t entirely phased out in the US until 1996.

Similarly, asbestos was seen as a breakthrough innovation when it was introduced. This stuff was amazing -- fire-resistant, an excellent insulator, durable and cheap. We used it everywhere in construction through most of the 20th century. It took 35 years from the first Surgeon General warning about the stuff until the EPA finally banned the stuff in 1989.

On the web today, we’re living in the age of leaded gasoline and asbestos. We’ve introduced innovation after innovation, disruption after disruption, but the thing we’ve disrupted most may be the web itself. Usability is at an all-time low. Sites are painfully slow. Basic functionality baked into the HTML spec for decades is broken. We optimize for marketing or developer experience while the people using the sites are left baffled by simple content that won’t load, back buttons that won’t work, and other erratic, janky behavior.

And that’s before we even talk about dark patterns, surveillance, disinformation, out-of-control AI energy usage and the other big, big problems caused by the web and technology in 2024.

We have reached a point where the most disruptive, digital transformation possible — the biggest innovation around — would be to simply make the damn web sites work.

Right now, they don’t work, at least not for the people using them.

Loading times have slowed.
Ads are more intrusive, often covering the content or reducing it to a postage stamp.
Forms are clearly optimized to extract data and without any sort of testing or user research to ensure they’re usable.
Auto-playing media annoys everyone but the companies trying to “drive engagement”
Important content is hidden or locked away behind registration walls.
Sites use misleading or deceptive practices to make it difficult for users to opt out, cancel or unsubscribe.
Privacy and account settings are baffling and hidden, leaving users sharing more information than intended.
Contact information is just gone from most web sites, so good luck if you have a problem.

And that’s at a personal level, before we even talk about the global lack of privacy and security, broken or non-existent accessibility, misinformation and hate speech and the growing environmental impact of crypto and AI tech.

Taken as whole it’s clear: Our never-ending focus on disruption has become destructive. We’ve coined and popularized the already overused term “enshittification” to describe our technological hostility to our own users, and yet we ply layer upon layer of AI and crypto solutions so we can monitor and manipulate those users.

What if we didn’t?

What if “human-centered” meant something beyond being a buzzword in the UX department? What if we put the same effort into making things work for users that we put into tracking them? What if we fixed the damn websites?

That would be transformative.

Hat tip to GSA Commissioner Robin Carnahan, for first saying “we’ve got to make the damn websites work.”

Photo is of a 1919 Red Cross-organized "Cleanup and Health Parade", from the Library of Congress.

DSCovery

2024-07-01T00:00:00Z

Over the past 10 years or so there's been something of a revolution in Civic Technology, as a whole bunch of firms have popped up promising to do better than traditional government contractors, who have an appalling record when it comes to building anything that works at all, let alone delivering it on time.

The Digital Services Coalition followed closely behind, working to build a sense of community for this new breed of civic tech firms promise to bring modern engineering principles, agile methodology and human-centered practices to government. From an initial handful of companies involved, the DSC has grown to include nearly 50 companies.

For someone like myself, who likes working in the civic tech space and would like to continue to do so, this presents a problem: I'd like to keep track of job openings in the field, but I can't go check 50 jobs pages all the time. I'm privileged with a lot more time on my hands than a lot of folks, but ain't nobody got time for all that.

So I thought I should build the thing I wish to see in this world, and created DSCovery to bring those job posts to me, and to anyone else who may be interested in them.

DSCovery is a not-particularly-complex Django/Python application that goes out to careers pages, retrieves new job posts from across the DSC organizationss and puts them all conveniently in one place.

As of today (July 1) it collects jobs from the following companies:

540
Ad Hoc
Agile Six
Analytica
Acquia
Archesys
AWL (All Women Leadership)
Bixal
Bloom Works
BlueLabs
Bracari
Capital Technology Group
Civic Actions
Clarity Innovations
Coforma
Corbalt
Exygy
Fearless
Metrostrar
MO Studio
Nava
Oddball
Pluribus Digital
Raft
Simple
Softrams
Skylight
Skyward
Truss
Verdance

I should note that any company's presence does not necessarily constitute an endorsement. I want to believe all the DSC firms are highly mission-driven and human-centered, but I also know there is a lot of variance in how different DSC firms approach the work. When interviewing, you should still ask smart questions to determine if any of these companies are the right fit for you.

There are also a lot of companies I'm not currently importing jobs from, and some of them are very good companies with fantastic people. In most cases, that's simply because they didn't have any openings and so I wasn't sure how to retrieve their posts. I'll be adding more of these to the mix over time, but for now, you won't find them:

Blue Tiger
Coa
Cognitive
Element
Flexion
Focus
For People
Friends from the City
Kind
Mediabarn
Mobomo
Simon
Snowbird
Valiant Solutions
Wheelhouse

What's next?

One of the things I learned as I put this together is that there are some really great civic tech firms that have decided, for whatever reason, to not join the DSC. I'll be adding some of them, too, starting with more firms in the Digital Women-Owned Small Business Alliance, which has considerable overlap with the DSC.

I'm also planning on introducing some methods to filter results by practice, and perhaps some custom user-centered views.

I'm also thinking about how I might pull in some job details, particularly salary info.

If you have thoughts on what you'd like to see, drop me a note in the repo issues.

Why did I do it?

Because I wanted it to exist, thought it might help other people, and nobody else was doing it. Story of my life.

What if something is broken?

Don't be surprised. This was a three-day project by a single person, and there will certainly be things that could be better. If you see something drop a note in the repo issues.

Where is it?

Trek 2100

2024-07-18T00:00:00Z

It's been awhile since I've written about one of my bike projects, yet somehow the house keeps filling up with them. This one's been with me since last October and I'm just now getting around to writing it up. The backlog is real, y'all.

Anyways, sometime last summer I got to thinking: I love these old steel bikes, but why not try something a bit newer? It might be nice to have a featherweight around.

I'd barely had the thought when this Trek 2100 turned up on my local marketplace, with an asking price of 80 bucks. How could I not nibble?

For those who don't know, the 2100/2300/2500 series was among Trek's earliest forays into carbon fiber in the early 90s, with CF main tubes bonded to aluminum lugs and an aluminum rear triangle via industrial adhesive. Based on the colors and graphics this one appears to be a 1991 model.

Over time similarly bonded bikes from that era have developed a pretty mixed reputation, with complaints about the bonding failing at the lugs. It may just be my imagination, but from my research it appeared that the bonded Treks were more highly regarded when new and appear to hold up well. Or maybe I'm just not smart enough to listen to the ominous warnings.

Either way, I went to look at it, haggled a bit and brought it home for $60. A steal. And I figured that for that price even if the frame was trash I'd come out OK on the components.

It looked a bit worn and unloved, but not bad at all.

As it turns out, the frame was pretty much flawless -- absolutely amazing condition, with no signs of oxidation, damage or bonding failure. There was barely a scratch or scuff to be found.

Overall, most of the bike wasn't in bad shape, although some failing grip tape and a sad sack Walmart saddle let it down, and there was no getting around the reality that a lot of the parts were well-worn early 90s tech.

From the front, a bit of grime, Sakae stem, Modolo 'ergo' bars and decent RX100 brakes. The ancient ride computer had to go.

A closer look at the hub shows more of the same: decent components, a lot of grime, and interesting splatter paint.

That's how you know it's carbon fiber. And a genuine US-made Trek.

The water bottle bosses are interesting, too.

So, what did I do with it?

Well, I'll tell you what I didn't do... take enough pictures of the rebuild. But that said:

I built up a new wheelset with DT Swiss hubs and rims and butted spokes, so I could move to a wide-range 11-speed drivetrain, rather than the original narrow range 7-speed.
That necessitated changing to a long-cage 11-speed derailleur, too I found a nice Ultegra derailleur for it.
Up front I needed new, compatible chainrings. I went with 50/34, married to a Shimano 600/Ultegra crankset I had laying around. I think I'll go to something with outboard bearings soon, though.
Shifting was moved from the downtube to Microshift bar-end, indexed for 11 speeds. I like bar-ends, but on this bike I think I might actually switch to brifters soon, just for a change.
Seat is a Selle Italia.
Bars are Soma Highway Ones (a fave) mated to a Nitto stem, but I think I may go back to the original Sakae/Modelo combo just of the period-correct vibe.

Final weight comes in just shy of 19 pounds. Not bad! I'm definitely not sure where I could skim too much more off without going deep into carbon parts. Which I may do someday. Or not.

Done. For now.

It goes to 11.

The original RX100 dual-pivot rim brakes are more than capable. The 'carbon fiber' brake pads just made me smile.

Very clean and tidy.

One more, just 'cause I like the pic.

So how is it to ride? Lovely. I was worried it would be a jittery beast, but it's not. Not at all.

It actually rides really, really well, especially given the stiffness of the frame and the narrow 25mm tires. It's by far the fastest bike I have, regularly coming in at a couple of MPH faster than anything else I'm riding. I mean, I'm still old and slow, but the bike is old and fast. It's also a monster when climbing. It just goes and goes.

I like it quite a bit.

Tasks

2024-09-04T00:00:00Z

The whole thing started on the Midwest Dev Chat Slack, when someone posted a screenshot from their work Slack that read:

The fact that we only have "Herculean task" and "Sisyphean task" feels so limiting. So here's a few more tasks for your repertoire:

Icarian Task: When you have a task you know is going to fail anyways, so why not have some fun with it before it all comes crashing down.
Cassandrean Task: When you have to deal with people you know won't listen to you, despite having accurate information, and having to watch them fumble about when you told them the solution from the start.
Odyssean Task: You'll complete but it will take 20 times longer than it should and involve multiple side quests and mini-adventures.

From those first screenshots it took off, with the wits on Midwest Dev Chat adding more:

Achillean Task: A task shipped with known issue.
Escherian Task: Looks achievable until you examine the details. (Not from mythology, but still pretty great.)
Hydraeous Task: The task you complete spawns two new tasks.
Theseusian Task: Scope creeps so many times, and so far, that philosophers spend centuries arguing if any of the original scope remains.

I liked these an awful lot, and I thought the smart folks on the Rands Leadership Slack would, too, so I posted them there, referencing the original MWDC posts. While I was already wishing I could take credit for the first batch, the Rands folks just went bananapants with the idea. This is the brilliance of those folks, not me, and all accolades are due them. Only one of these is my own original thought. The rest come from the minds of smarter, more creative (and apparently better read) people...

Atlassian Task: you’re writing all the Jira tickets.
Chronean Task: Didn't I already do this task?
Damoclean Task: A task you enjoy doing, but there is always this underlying sense of foreboding and anxiety while doing so.
Diogenian Task: absolute dog's work, but better than talking to people
Dionysian Task: Who cares, it's Friday.
Epicurian Task: I just like doing it this way.
Gordian Task: Instead of doing the task, you delete the ticket or maybe the whole epic.
Gorgon Task: Whenever you approach someone about your task, they stonewall you.
Kronusian Task: Driving away people that threaten your power and position.
Minotian Task: Just a lot of bull.
Midasean Task: a very lucrative endeavour, but might leave you feeling hungry for more substantive work.
Narcissian Task: Just make it pretty.
Orphean Task: you have to write this entire service in isolation, but the moment you run one integration test the other services will block you.
Pandorean Task: When you have a task to do that you know will unleash chaos on the world when complete.
Poseidan Task: When you are drowning in the work.
Penelopean Task: same as an odyssean task but nobody talks about it because it is a woman doing it.
Promethean Task: Do some hero work for your team and then get picked apart by upper management for all eternity.
Siren Task: Your sole task is to distract others from doing their tasks.
Trojan Task: I'm only doing this task so I can sneak this other thing into the next release.

So there you go, there they are in all their glory, with a few small minor edits. I hope you enjoy them as much as I did.

I did leave a few off the list here if they duplicated others, if I am not smart enough to understand the reference, or if I just flat missed one. Forgive me.

Artwork: "Sisyphus" by Jeffrey Hummel

Contributors (who wished to be identified) include Blaise Vignon, Caleb Huitt, Steven Harrison and Michael Van Nieuwenhoven. Thank you all, smart and funny people!

If you submitted any of these and would like to be credited, please let me know via a Github Issue. Or if you know my email address, just shoot me an email. That's fine, too. Be sure to tell me how you would like to be credited.

Another one?

2024-10-16T00:00:00Z

Within days of finishing up the Monark/Road King resto-mod another rough and down-on-its-luck old cruiser popped up and I couldn't resist. I mean, for $25 it was this or a light lunch at Chipotle. So I bought the bike.

As I found it.

This one is also a Monark-made frame (a twin to the last one) but without any badges I don't know if it was originally another Road King, or maybe a Monark Rocket, or some other badge-engineered Monark. I just know it's the same frame, and from the same era: mid-to-late 40s.

And it is definitely in rough shape, maybe worse than the last one, with a bad home paint job and plenty of rust.

I believe I'll either build this one up as more of a rat rod, or just a nice classic cruiser. Should be fun.

Road King

2024-10-16T00:00:00Z

Let's start this story in the middle of the 20th century, when consumer confidence was high, unions were strong, and American factories were working overtime to satisfy consumer demand and new-found discretionary spending.

Against that backdrop a strange sort of amalgamation of hardware/auto parts/durable goods store was common in even the smallest towns in America. Western Auto and Firestone may have been best known, for these types of stores, but they were far from the only ones.

Obligatory photo of the historic Western Auto building in Kansas City.

At the time, the Sieberling Rubber Company was one of the biggest tire companies in the US, and just like Firestone and other tire makers, they ran a chain of these odd retail stores, selling their tires, car batteries and other various things... including bicycles, which they sold under their "Road King" brand.

And since Sieberling wasn't in the business of making bicycles, they contracted that work out to several different companies that once dominated US bicycle manufacturing.

So that's how the now largely forgotten Monark Silver King bicycle company of Chicago found itself contracted to build this bike:

1948 Monark-made Road King bicycle.

Which found its way to me recently.

Monark ceased to exist after 1957, following a buy-out by Huffman/Huffy. Sieberling Rubber made it to the mid-60s before being gobbled up by Firestone, and then later becoming part of the multinational Bridgestone corporation.

I started out buying a classic cruiser, I got a lesson in America's 20th century manufacturing boom and bust. The bicycle is going to get a lesson in how bicycle technology has progressed over the past 75 years.

But, about that bike: I had been wanting to build a classic "Klunker" for awhile. When this one turned up on the local marketplace, I liked the details of the frame, so I threw out a low offer and was surprised when it was accepted. Next thing I knew I was driving a half-hour out of town to pick it up. Once I got it home I took some pics to document the "before" state...

At some point long ago it had been repainted. Possibly with house paint. Also, I've never seen a stem quite like that one before.

I believe the drivetrain was all original, possibly even down to the pedals. I do know this: our grandparents mashed some big gears back then.

I really like the filet-brazed frame and the unusual seatstay and chainstay arrangement. I was less thrilled to discover a possible crack by the seat clamp.

I don't think I'll be keeping this old Mesinger seat. You can get a better view of the neat seatstay arrangement, though.

I pretty much immediately began stripping it down, and was really pleased with how easy that went. I was prepared for every bolt to be stripped, a rusted-in-place seat post and stem, and all sorts of other horrors. But really it came apart with no problems, just a little penetrating oil and patience.

Stripped down, it weighed in at 8 pounds. No featherweight, to be sure, but only a few ounces more than a modern aluminum mountain bike frame I won't shame by name.

When I took out the rear fender about a half-cup of trapped water came dribbling out of the frame.

Since the frame was originally built with 110mm spacing for a coaster brake hub, it was going to take a BIG cold-set to fit a modern cassette hub in there. It took a lot of patience and careful checking of alignment, but the old steel took the set well. It now sits at 135mm, ready for modern hubs.

Test-fitting with a spare wheel I had laying around. The string is there for double-checking alignment.

I really debated what color to paint it, but the bike kept telling me it wanted to be white. So I listened. Here it's been sprayed but still needs final wet-sanding and polishing.

That's as far as I made it in the first week, but parts were on the way.

August 18: Polishing, modernizing & test-fitting

After wet-sanding and polishing, I was pretty happy with the finish.

You really can get good results from a rattle-can paint job, but it takes a lot of patience and work. I'm willing to work, but not always patient enough. Nevertheless, I was pretty happy overall with the paint after wet-sanding and polishing, especially considering the number of nicks and divots in the nearly 80-year-old steel. I may still give it a bit more love, but it's really looking pretty good to my eyes.

The original headbadge also cleaned up nicely. I wish some prior owner hadn't "touched up" the paint, but I'm not going to try to correct it -- it can wear it's history. I just wanted to polish the grime off and bring back some shine.

Conversion kit.

I put in a nice bottom bracket conversion kit so I can use modern three-piece cranks. I also had a strong and light Sunlite bottom bracket with chrome-moly spindle in the toolkit, so that will save a few grams, too. I considered external bearings and a hollowtech crank, but I'm not sure how well they'd play with the conversion kit, and good quality square taper stuff isn't much heavier at all. Plus I have a lot of good square taper stuff laying around already.

And another conversion kit.

This bike pulled another rabbit out of its hat up front, where I've fitted a threadless headset. Basically, these old American frames used a head tube that's within a gnat's whisker of the modern 1 1/8 standard, so some enterprising souls have taken machined about 0.01 inched off a modern alumninum headset and voila it all fits.

I had a fork I had purchased for the build, but when I put it altogether it looked goofy. So for now I've put a parts-bin GT fork on there, and I actually kinda like it, even in the partially sanded unfinished current state.

Testing bars and stem.

Since I was throwing some parts-bin bits at it, I added a stem and some bars. Not exactly what I'd envisioned, but I like them for now and the price was right.

Sept 22: Wheels!

I knew when I decided to paint the frame white that I was going to have to introduce some visual interest elsewhere, so I decided to make some pretty flashy wheels, starting with some red anodized SE Racing Wheels.

Very red rims.

Because BMX and cruiser rims are nearly universally 36 holes, I was a little limited in my choices for 36H disc hubs, but Shimano came through with suitable Deore hubs for a great price. The whole thing was laced up with double-butted black spokes and chrome brass nipples. They are definitely eye-catching.

Lacing the front was straightforward.

But lacing up a disc rear was far from straightforward. It just about broke my brain, and I had to lace it up 3 times before I finally got it right. The tape was there to help me keep track of things.

Once they were finally tensioned and trued, I slapped some Schwalbe Billy Bonkers tires on -- probably my favorite 26" tires -- and they were ready for the bike.

Connecting a derailleur to this thing was going to require an old school claw hanger, and it's surprisingly tough to get a decent one nowadays. A lot of them are very thin and flimsy, or even unthreaded. Next time I take apart an old bike with one, I plan to keep it, as the old ones were clearly made better. But it'll do.

There's a lot more happening on the drive side than Monark ever intended.

I dug around in the parts bins and found a little dropout spacer for the other side that I'd saved from some prior project. I wish I knew where I got it, 'cause it's pretty handy.

Non-drive-side dropout spacer.

I was really surprised by how easy the disc brake conversion went. Disc brakes are surprisingly cheap, and the little disc brake converstion/adapter bracket worked way, way better than I expected it to, at least in this case. They don't work in a lot of cases, but on this bike they worked without much trouble. I was shocked. Everything just worked.

The brake side also has a lot more going on than Monark ever intended.

Cables were managed by some little clip on guides that were pretty slick.

The seat was a bit of a hiccup, as the original post measured 21.78 mm, and nothing is that size. Nothing. So after looking fruitlessly I decided not to worry about it and just cleaned up the original as best as I could. I did have a nice Charge saddle that completed the white/black/red motif.

Most of the other stuff was left over from other projects. Pedals, cables, even the crankset, it was all just laying around, so I went ahead and built it up, at least to establish a baseline.

Freshly built.

The rear

And the front

The baseline is good. It's a fun, fun, fun bike. That said, there are some issues I need to address:

I still want those big klunker bars, with a bit more rise.
I need to either pick up a disc brake fork or fit some V-brakes on the front (and risk messing up that pretty red rim).
It needs a spacer under the stem. Right now there's too much movement.
The disc brake isn't adjusted quite right and tends to squeal.
I don't like the derailleur I used and need to clean up a better one.
My cabling could be a lot tidier.

None of this stuff is particularly surprising with such an involved build, and none of it is all that hard to sort out.

October 16: Sorting it out

I continued tweaking and tuning and sorting it out. With a big custom build like this one, it's not surprising.

At this point, I've taken care of most all of my to-do list above and the bike is riding much better. Probably the most visible change is the switch to some massive BMX cruiser bars. This entailed re-cabling, swapping out the shifters and brake levers, and a lot of other small changes. I'm not sure it was worth it, but they do look cool.

The complete bike, hanging out by some rocks.

A rear view of the 'finished' bike.

Honestly, I may revert back to the low-rise bars. I haven't decided. I'm feeling pros and cons each way.

But regardless, I think that's about it for this bike, at least for now. Maybe after riding it a bit I'll think of something else I want to do. For now, though, I think I can call this one finished.

That's good, because I've already bought the next one.

Engineering velocity

2024-10-17T00:00:00Z

It's a question I've heard a lot over the years, from a lot of frustrated managers and stakeholders. They can't get past it.

"Seriously, why are my engineering teams so much slower than they used to be?"

I get it. The frustration is palpable. A team that used to cook along now appears to be stuck in molasses. They get slower and slower, and it's confounding to everyone waiting for the next major feature to be delivered, or even just looking at a burndown chart. It can be confounding and frustrating to the team, too.

But I'm here to tell you, the frustration is likely misplaced: Teams slowing down as they mature and grow is not only normal, it may be better.

After looking at the velocity of dozens -- possibly hundreds -- of teams over the years, and how it changes over time, here are the common threads among the "formerly fast" teams.

They finished the fast part

Everything moves a lot faster when you're a cowboy, riding breathlessly across green fields. You can shift direction on a whim, you can explore, you can strike out in bold new directions. That's fast, and it's easy. But getting from something to something good takes a lot more time and effort.

No matter what the project, from software engineering to home renovations, smart people know that the first 80% is the easy part, and the work goes quickly. But the last part -- the sorting out and polishing -- takes much, much longer.

They're swimming in a bigger pond now

In the early days, engineering efforts usually start off as an experiment, or perhaps a small team carefully curating their own little walled garden. But as the team matures and the codebase grows, it inevitably becomes part of a larger ecosystem. There are APIs to integrate and platforms to build on. Which means you are now part of an ecosystem. Ecosystems introduce interdependencies, and interdependencies slow things down.

When you were a young team you could do pretty much whatever you wanted, so long as you got your homework done. Now you have to play nice with others. You have to get permissions. You have to stop to read the instructions. These things take time.

They were good. Let's throw a party.

And finally, success leads to slowdowns. Only successful programs live to grow and mature, which means as programs grow and are seen by more people, more people have thoughts.

Or, to put it another way, early on a team may only have to satisfy an idea, while later they have to satisfy a whole org chart. As more eyes are on the team, more demands are made.

The team may be cranking along like the same high-efficiency machine they've always been, but more demands means more backlog. While the throughput may not change, the time to satisfy any one request may get a lot longer, which makes each individual stakeholder think the team is now slower than they used to be. They're not, they just may be slower to get to your request.

This is still a good team.

The irony is that all those factors are positive outcomes of a successful, maturing team. They are also, notably, largely out of control of the people on the team.

But still, most discussions around improving velocity start from the perspective of "how do we get these teams to go faster." And the short answer to that is that you don't. Assuming the team is continuing to work well together, then any perceived slowdown is probably not true -- they're likely working as fast as they ever did -- and also ignoring how the team and program has matured and works in a different context now.

So if you're a team getting hit with questions about why you've slowed down, what can you do?

Take a look at part two!

Engineering velocity: Part 2

2024-10-22T00:00:00Z

Last time we covered a lot of reasons why that once-fast team has slowed down. If you haven't read that part already, you should, but to give a quick recap, those were:

This time, we'll talk about what you might be able to do about it.

They finished the fast part

The first 80% is always the fast part, right? It's just the Pareto Principle in action: You get 80% of the benefit for 20% of the overall effort. But the rest takes 80% of the total effort -- and time. Which people notice. So the paradox is that while the team is now putting in more effort, people are seeing less output.

Shifting how you approach demonstrating value can help here. Instead of demonstrating things being delivered, try to shift to demonstrating problems being solved.

Early on, it's easy to show the tangibles the team is delivering. But that inevitably slows down as the project matures. Teams find themselve spending more time solving more complex problems, with less visible forward momentum.

It's not that progress isn't happening, it's that it's not visible. Make it visible. Enlist a designer to help illustrate the problem. Have a product manager help build a timeline showing the invisible capabilities that have been delivered. Talk through the systemic issues that have been worked through. In short, shine a spotlight on the the hidden work and bring it out of the shadows.

They're swimming in a bigger pond now

As a project matures it always seems to connect more and more to a larger ecosystem. Maybe the work gets so big it gets split across multiple teams. Maybe it becomes a platform other teams are building on. Maybe it comes to rely on a platform itself. Maybe they just have more APIs they're relying on for more features. No matter what the specifics of the story may be, the outline is the same: this work is part of a larger whole.

Which means you now have a hand-off problem, which goes something like this:

On November 1, Team A decides they want to do small-thing, so they add it to their next sprint, starting Nov 11.
About a week in, around Nov 19, they realize they can't complete small-thing until Team B does other-thing. Team B says "Hey, no problem, we'll add it to the next sprint!"
But Team B's sprint just started on the 18th, so their next one won't start until December 2.
And then, in sprint planning, a senior engineer pipes up to say "You know we can't complete other-thing until Team C resets the config on the thingModulator."
So now it bounces over to Team C, who thankfully get it into their next sprint, starting December 9. They get the config change done quickly so it can get back to Team B, just in time for their December 16 sprint.
Team B also gets the work done quickly, as promised, in time for Team A to finally do small-thing in their next sprint -- which is a holiday sprint starting Dec 23.

And that's how a bunch of teams can work really hard, really quickly, and really concientiously, and yet it takes more than eight weeks to get small-thing done. And there's not a whole lot you can do about it.

But you can try:

identifying dependencies as early as possible. Long before the story is about to go into a development sprint. Track them, get them done as part of the work (and again, show and demo that work as it gets done).
Aligning sprint start dates across teams can help. Sometimes.
Lobby for config changes and small dependencies to be handled as they arise, either kanban-style, or by keeping some capacity within the existing sprint cycles.

They were successful

If a project is successful, it grows. As it grows more eyes are on it, and more demands are made. This is another case where the team has to show all of the work they're doing, that includes the less-visible work, as discussed above. It also includes making their priorities very clear and public. If Stakeholder A isn't getting what he wants because all of the efforts are on Stakeholder B's initiative, everyone involved should see that trade-off.

If a project becomes really successful, it might develop into a platform other applications and teams rely on. Which means they're slow by intent. Platforms optimize for reliability and stability, not speed. For a small project, application, or site, it only has to work for a small group. For a platform, it has to work for every consumer and team in the ecosystem.

Just the layer between the platform and the application teams building on it can be a source of slowdowns. For application teams leveraging the platform, enhancements depend on the platform team implementation timeline. For the platform team every deprecation and migration is an exercise in waiting for all the application teams to upgrade -- and that happens at the pace of the slowest team.

They're still good, it's just the perceptions that have changed

We've already covered how teams often fail at highlighting all the progress they're making, which in turn feeds the false perception that they're slower than they used to be.

The irony is that false perception can actually make the team truly slower. It goes like this:

Over time the team natually picks up tech debt, bugs, and hidden work.
Like most teams, they don't do a great job of showing that work.
People start pushing them to "increase velocity."
The team responds by prioritizing quick wins, which means they're not focused on bug fixes and work that enables more meaningful forward momentum.

Which means they end up slower than they were before they started. It's like a company so focused on short-term earnings that they don't do the hard work of staying in business (GE is a great recent example).

Show the work

If there's one takeaway here, it's that good teams usually don't get slower as they mature, they get more complex. In complex systems sometimes you go slow now because it will make you faster later. Sometimes you're not going slow at all, but people aren't seeing all that's happening. In either case, illuminate them.

“Velocity” can mean a lot of different things depending on the context and who's throwing it around. It's like a hex, and the best defense against the dark arts is the bright light of day. So never fail to shine a light on the work.

The big exception is platform teams, which are slow by intent, but even then, they're enabling application teams to be faster. Show that.

Show the work.

Photo is reportedly of a 1930 incident where a bunch of elephants escaped a vaudeville show in New York, but I can't confirm. If anyone has a link to the story, I'd love to hear about it.

If you'd like to read more about why platform teams may be slow, my friend Mark Headd and I once wrote quite a bit about it: The Platform Smells Playbook. Mark is wicked smart.

Skipped teeth and blockchains

2024-10-24T00:00:00Z

So I recently bought an old bike -- nothing new for me -- but as I was poking around on it, I realized something was unusual: I'd bought a skiptooth bike. I had questions.

So first, what is a "skiptooth" bike? Without getting too much into bike nerdery (I do that plenty elsewhere around here) the basics are this: Modern bike chains have 1/2" between their pins, but that wasn't always the case. Up until around 1950 or thereabouts, most chains used an uneven one-inch spacing, with long links alternating with short links between rollers. This was called "skiptooth" because the sprockets were missing one tooth in between each tooth. They skipped those.

What? Yeah. Take a look at the picture above to visualize it, cause it just seems weird. Why not just make them all the same size?

Because it was mimicing an earlier 1" spacing standard from the 1890s or so called... wait for it... "blockchain."

The original blockchain literally had big 1" steel blocks, with short linking plates between them. I believe the thinking was to limit the amount of parts that bend so it would be stronger. This didn't work nearly so well for bicycles as it did heavy machinery, but it was the first viable bike chain.

An example of a blockchain as used for a bicycle. Photo from thecabe.com.

The difference, of course, between this 125-year-old tech and the modern blockchain is that a bicycle blockchain actually solved an identifiable problem.

Blockchains were inefficient and clumsy -- some things never change -- and only lasted about 20 years or so before they were replaced by the much more flexible, quieter skip tooth, which lasted about 50 years before being replaced by the standard chain spacing we've all been using for the past 75 years.

SkipToothChain: the next big thing.

I'm not proud. After all, I did make https://dadjoke.fly.dev.

Backpacks

2024-11-15T00:00:00Z

Everyone has a backpack, and everyone has stuff in their backpack.

Sometimes your backpack has too much stuff in it, and you've got to get rid of something.

Sometimes your backback may not have all that much in it, but that stuff is heavy and it's hard to carry around.

Most of us are carrying some stones in our backpacks. These are heavy loads. Sometimes we carry those rocks for years. Some of us have backbacks so full of rocks nothing else fits in there. We can barely lift the pack at all, let alone carry it all.

People will often want to give you something that was in their backpack. In some cases, that may be a gift.

"Hey, this is so cool, you think, as you tuck your new treasure carefully away in the backpack, hopefully far from the rocks.You'll be happy to carry this wonderful new thing in your backpack, and even though it's in there, the pack somehow feels lighter.

Other times it's just another rock for you to carry around.

You don't always get to choose what's in your backpack, but when you do... choose wisely.

Every day, some people are carrying overloaded packs. If you can take some of their load and help them, that's good. If you can't, well, carry your own load as best you can, and maybe you can help more on down the road.

Sometimes you just gotta put your backpack down for a minute. That's ok. Take a breather. But you can't leave it behind. There's important stuff in there.

Yes, this is a metaphor, one that I've belabored before, and will belabor again. It works for me. I like having it in my backpack.

It may not work for you. You may think, this is just a different metaphor for what Spoon Theory already describes. I disagree, but that's OK, I'm not asking you to carry my metaphor around if you don't want to. And I don't plan to carry your opinion of my metaphor around either.

Carry what you need and want. Sometimes carry more, if you can, or if you want to.

Don't be afraid to leave some rocks behind.

Building DSCovery

2024-11-18T00:00:00Z

I was asked today how I built DSCovery, the aggregator I put together awhile back to help people find jobs in civic tech.

I wish it was a better story.

The reality is that on a technical level it's a not-very complex Django app. I just love Django for this sort of thing. You can get from zero to something in no time at all. Rails has the same advantages, but I know Django much better, and the Django admin made my life a lot easier in this case. It was kind of the killer feature for this project.

But, to back up a bit, aside from Django I already had experience with two things that would be key to DSCovery:

I had used BeautifulSoup to scrape sites for various reasons, like hitting the Secretary of State site for election night returns back in my journalism days. I wasn't at the Lawrence Journal-World, but James' Bennett's classic rundown of what that usually looks like seems pretty universal.
I had spent enough time with various ATSs that I knew what their output tended to look like. For those who don't know, an ATS is an Applicant Tracking System -- The thing recruiting uses to keep track of open roles and who's applying for them.

Because I'd spent so much time with ATSs as a hiring manager, I knew there weren't that many of them out there, and most folks congregated around just a few. Which meant that if I wrote the importer for one, I'd written it for all of them.

So I started going down the list of DSC firms using the most common platforms and started building an importer for each platform, as simple as possible:

For each company known to use this ATS platform....
Use the Requests library to get the HTML from the jobs page
Use BeautifulSoup to parse the jobs out
Tuck them away in a python data structure.

This got easier as I added more companies, because more often than not I could re-use an importer I'd already written. When I was fairly happy with the first importers, I built a view to wrap them and do a few things:

Clean up old and/or unreachable jobs to keep things fresh
Set up the data structures for the importers
Pull in each of the importers as a module and runs them.
Take the data structure, do any last-minute cleaning, and write the new records to the database.

From the Django admin I can then keep an eye on the roles, assign them to different practices, set things as featured etc.

And really, that's about it. There are a few basic display views, but not a whole lot more. I've got some more things I'd like to do when I find time, but right now it's still pretty simple.

I recall doing some almost-interesting things with includes in the templates to make them more reusable, and to allow me to more easily use Alpine.js and/or HTMX, but if I'm being honest I can't recall now what it was that I was doing with Alpine.js or HTMX, and I'm not sure if I ever implemented it publicly.

The challenges

There were a few challenges along the way, to be sure, and some of them have persisted.

For example, some of the ATSs are really difficult to parse, usually because they use client-side rendering (side note to ATS vendors: a jobs page is nearly the last place client-side rendering makes any sense). This borks BeautifulSoup because it sees the page as it was delivered from the server, not as it's hydrated client-side. Or, in other words, it sees an empty page.

In some of those cases I've been able to find the raw JSON it's hydrating the page from. In those cases I sidestep BeautifulSoup, grab the JSON and parse that. But in other cases the JSON is also unavailable and I'm stuck. Workable, for example, just seems unparseable, so I can't yet import jobs from Blue Tiger, Friends from the City, or Pixel Creative. That bums me out. They're good folks.

And some ATS are just completely stupid and awful to work with. Usually, but not always, these are old-school "enterprise" offerings that feature lousy markup and horrific user interfaces: ADP, ApplicantPro, UKG, that sort of thing. I really feel for the companies saddled with these systems.

In some cases (like, Ad Hoc, for example) I think the company is important enough that I really want to include them, but their ATS system is so incredibly bad that it's just impossible. All I can do is pull from LinkedIn. It's not ideal. To all the DSC companies (and anyone else who'll listen) listen to this advice: Don't listen to fools trying to sell you these "enterprise" ATSs. They are garbage, and the person trying to convince you to switch to them should not be listened to.

There are also some cases where the ATS is too niche, or the companies are so small, that I'm waiting for some more jobs to import before going through the effort of writing a new importer.

At any rate, I continue to iterate, add more firms, and more functionality.

The whole thing is hanging together pretty well so far, which makes me happy. It'd been awhile since I'd coded up much of anything, really, so I was glad to see I could still do it.

If you'd like to read more about DSCovery and why I built it, I wrote that up awhile back. If you'd like to take a look under the hood, all the code is public.

Photograph is of a Side Corridor on a Dirigible, ca. 1933, from the National Archives

This is where it all breaks

2025-05-30T00:00:00Z

Let’s skip past the philosophical debate — there’s been plenty of that already (including some here). Whether or not you should, you did: you bought into AI. You committed your teams to building AI-driven solutions, and you’re starting to ship them.

You are in it. Or rather, AI’s in it. And then things get complicated.

Because, as usual, the hard part isn’t really the technology, or even integrating it.

It’s the world around it.

That’s not an AI problem. It’s a service design problem.

Systems are like people: they're messy and they often don't make much sense.

A lot of software up until now has been built on the dream of reducing human messiness down to a clean loop: human asks → software responds → happy human.

But real systems rarely end up like that. They’re often more like:
human asks → website makes API call to CRM → help desk → someone in compliance → another tool → export to spreadsheet → escalated to manager → judgment call → back down from manager for data entry → backend system → another person copy/pasting → software pushes results to other systems → human gets an email days later.

Yet somehow, in 2025, we seem to think we can reduce that to:
human asks → AI responds → happy human.

The real world is full of handoffs, mismatched expectations, missing context, and partial automation duct-taped together so people just trying to do their jobs may actually succeed most of the time. More importantly, even when they're doing their best, those people are inconsistent and make mistakes — because they’re human. This is the mess that service design has always tried to make sense of.

Service design isn’t just about the user journey on a screen. It’s about the whole system — who’s doing what, with what tools, at what point, and what happens when that handoff goes sideways.

It pays attention to the awkward stuff: the delays, the workarounds, the “I guess I’ll email someone” moments. The parts where two systems almost work together, but not quite. That’s where services tend to break — not just what the user sees, or even what the engineers build, but in the in-between and the edges.

What Changes When You Add AI?

Everything. And nothing.

AI doesn’t just drop into an existing step like a new library or subsystem behind a feature flag. It reshapes the dynamics of the whole system. That’s because AI is introduced to replace one of two things:

Predictable but limited deterministic process, like code, workflow, or rules
A human with judgment, context, and fallback instincts

In the first case, you lose the predictability and testability. In the second, you keep the all the human weirdness without the innate paths to fixes.

Example 1: AI in Customer Support

Let’s say you’ve got a chatbot handling support. It answers questions, escalates tough ones, runs 24/7.

But what happens when:

It confidently gives the wrong refund policy?
It tells a customer to do something that voids their account?
It doesn’t escalate because the person didn’t phrase their problem the right way?

Now the human on the other end isn’t just annoyed — they’re angry. They’ve been misinformed, misunderstood, and made to feel powerless. The AI made the problem worse.

And what happens to the remaining members of your human support team? They’re now cleaning up, not just answering questions. They're managing emotional escalations. They're carrying the risk of an AI that doesn't know what it doesn’t know.

They are the last line of defense for a system failure.

Example 2: AI in Internal Tools

Let’s say you give a policy analyst a tool that uses AI to summarize regulatory comments from the public. Hundreds of thousands of them. Saves time, right?

But then:

The summary misses a key legal objection raised by multiple stakeholders.
It flattens nuance into something “neutral” but meaningless.
It leaves key details out, but the analyst doesn’t know what got left out.

Now you’ve reduced transparency and increased risk. The AI didn’t just summarize — it reshaped the evidence base for policy.

If the rest of the system wasn’t built to catch that, you don’t have a model problem. You’ve got a service design problem.

Wait — Don’t Humans Make These Mistakes Too?

Yes. All the time.

They misread. They skip steps. They make bad calls under pressure. But at the same time...

1. Humans don’t make mistakes at AI scale. An AI can repeat the same bad output hundreds of times in seconds. A person can’t.

2. You can train (or fire) humans. There’s a feedback loop. With AI, that loop is harder to build and slower to act on.

So no, the bar isn’t “perfect accuracy.” If AI performs roughly as well as a human — and you can catch its mistakes — you're no worse off than you were before, and you may be much better off. That's good!

Design for the Drop, Not Just the Lift

This is the part we skip too often. We talk about what AI adds — the “lift.”

But every time you add AI, you’re also removing something:

Human context
Transparent decisions
Known error types

That’s the “drop.”

If you only design for the lift — and ignore the drop — you’re building something brittle.

Designing for the drop means asking:

What context did this rely on before?
Can the AI replicate it?
What happens when it gets it wrong?
Who notices?
Who can recover?
Are downstream humans ready — and do they have enough info to fix it?

If your service falls apart silently when the AI outputs garbage, then the service isn't well designed, is it?

AI Makes Service Design More Important — Not Less

If you’re introducing AI, you’re taking on more responsibility:

To define the seams
To build guardrails
To enable recovery
To preserve accountability

That’s not a better prompt. It’s not a fine-tune. It’s not tweaking your retrieval chain.

It’s designing a system where people — not just models — can succeed.

One More Thing

The worst failures won’t look like outages. They’ll look like slow erosion:

Trust lost without a clear breach
Bad decisions built on subtle misfires
Teams overwhelmed cleaning up silent messes

If you’re not designing the whole service — inputs, AI, outputs, context, escalation, recovery — you’re not designing a system.

You’re just crossing your fingers.

Hope isn’t a strategy.

Service design is.

Vintage bicycle projects

2025-05-30T19:40:27Z

The bedraggled Raleigh
A bound-for-the-dumpster Raleigh Sports gets a new lease on life.
Peugeot mixte restoration
Parlez-vous français?
Trek 520
A great bike, with a few caveats
Making wine cork handlebar plugs
Want something different for your handlebars? How about a wine cork bar end? They're easy to make.
The electric Schwinn
My e-bike conversion on a 50-year-old Schwinn.
The Luxus folding bike restoration
For some inexplicable reason, I wanted a vintage folding bike.
The handcycle
An interesting journey into making bicycling more accessible.
Trek 2100
What? A carbon fiber bike? In this house? Well, sort of...
Another one?
Another bedraggled classic cruiser finds its way to my house.
Road King
Bringing a 1948 cruiser bicycle into the 21st century.

Fiberglass "egg" camper restoration

2025-05-30T19:40:27Z

1971 Eco fiberglass camper restoration
Trying to put an egg (camper) back together again.
Making a smart vintage camper
My attempt to bring modern tech to a very old camper.

Web Things

2025-05-30T19:40:27Z

Maturity Model Generator
Need a maturity model? Just enjoy a silly joke? Either way, we've got you covered.
The giant list of questions to ask employers
Do you get sytmied when you're asked if you have any questions in an inteview? Have we got a list for you.
Pear
Comparing text from two documents easily, with no sign-up or data sharing.
Not funny, Dad
The end result of a fascination with obscure government data sources and dad jokes.
Markitup (v2)
Bringing an old favorite jQuery library into the modern era. And some musings on ChatGPT.
Deploying
A running list of the questions I have to remember to ask myself when deploying a new app to a new environment.
11ty Linkrolls
How to build an old-fashioned linkroll for the 11ty static site generator.
About this site
We're doing it live! Whatever this site becomes, we're gonna build it out in the open so everybody can see all the half-baked ideas and dead ends.
DSCovery
Building an aggregator for jobs in civic tech.
Building DSCovery
How I built DSCovery, the civic tech jobs aggregator, and lessons learned.

Selected writing

2025-05-30T19:40:27Z

The Five Conditions for (Organizational) Improvement
Understanding why organizations get stuck and won't change
Quicksand meetings
Managers: Avoid these sinking meetings so your teams don't feel stuck.
Know your (documentation) audience
Why nobody likes your docs and your Single Source of Truth isn't working
So you don't want to be a manager
Straight talk to a senior engineer wanting to stay on an IC track.
AI is boring and stupid and maybe that's OK
Sometimes boring and stupid is still really useful.
On values
What we care about costs us.
We’ve got to make the damn websites work
Is it the most transformative thing we can do on the web in 2024?
Tasks
Herculean tasks, Sisyphean tasks, what else have ya got?
Engineering velocity
Why is my engineering team so much slower than they used to be?
Engineering velocity: Part 2
Your team seems slower... Here's what to do about it.
Skipped teeth and blockchains
Down a different blockchain rabbit hole.
Backpacks
How are you carrying your load?
This is where it all breaks
AI, service design, and the real work ahead

Another Rodeo

1971 Eco fiberglass camper restoration

1971 Eco camper restoration#

So what is this thing, anyway?#

The teardown#

Troubleshooting power issues#

Why did I do it?#

What did I learn?#

Where is it?#

The bedraggled Raleigh

Reassembly#

The rear wheel - spoke replacement, tensioning and trueing.#

Final steps#

August 2020: Goodbye, Raleigh#

Making a smart vintage camper

Wiring a Pi power switch#

Installing a motion sensing camera#

Testing the motion sensor hardware

The motion sensor code

Setting up a local web server#

Adding the touchscreen#

Creating a dashboard#

Weather

Plex

Camera

Wifi Status

Time/date/messages

Trimming the touchscreen#

Setting up audio#

Addendum: Setting up the Pi from scratch (as of May 2021)#

First, get an OS on the Pi#

Install Plex#

Pi Configuration and further installations#

Code setup#

Peugeot mixte restoration

November 2020: Paint#

December 2021: Rebuilding and enjoying the Peugeot#

July 2021 - Goodbye Peugeot#

Trek 520

Making wine cork handlebar plugs

The electric Schwinn

How does it ride?#

What did I learn, and what would I do differently?#

April 11 update#

Maturity Model Generator

Maturity Model Generator#

Why did I do it?#

What did I learn?#

Where is it?#

The Luxus folding bike restoration

February 2021: Cleaning and sanding the Luxus#

March 2021: Bad conditions and worse paint#

May 2021: The wheels go round and round.#

September 2023#

The giant list of questions to ask employers

Questions for potential employers#

Table of contents#

Getting started#

Culture#

Work/life balance#

Bureaucracy#

Diversity, equity, inclusion, belonging, and ethics#

Understanding the company and team#

Leadership#

Doing the work#

Career development#

Performance evaluation#

Compensation#

For engineering orgs#

Things to look for in real life#

Pear

Why did I do it?#

What did I learn?#

Where is it?#

Not funny, Dad

Why did I do it?#

What did I learn?#

Where is it?#

Markitup (v2)

Why did I do it?#

1971 Eco camper restoration

So what is this thing, anyway?

The teardown

Troubleshooting power issues

Why did I do it?

What did I learn?

Where is it?

Reassembly

The rear wheel - spoke replacement, tensioning and trueing.

Final steps

August 2020: Goodbye, Raleigh

Wiring a Pi power switch

Installing a motion sensing camera

Setting up a local web server

Adding the touchscreen

Creating a dashboard

Trimming the touchscreen

Setting up audio

Addendum: Setting up the Pi from scratch (as of May 2021)

First, get an OS on the Pi

Install Plex

Pi Configuration and further installations

Code setup

November 2020: Paint

December 2021: Rebuilding and enjoying the Peugeot

July 2021 - Goodbye Peugeot

How does it ride?

What did I learn, and what would I do differently?

April 11 update

Maturity Model Generator

Why did I do it?

What did I learn?

Where is it?

February 2021: Cleaning and sanding the Luxus

March 2021: Bad conditions and worse paint

May 2021: The wheels go round and round.

September 2023

Questions for potential employers

Table of contents

Getting started

Culture

Work/life balance

Bureaucracy

Diversity, equity, inclusion, belonging, and ethics

Understanding the company and team

Leadership

Doing the work

Career development

Performance evaluation

Compensation

For engineering orgs

Things to look for in real life

Why did I do it?

What did I learn?

Where is it?

Why did I do it?

What did I learn?

Where is it?

Why did I do it?

What did I learn?

Where is it?

Why did I do it?

What did I learn?

Where is it?

OK, great, now what am I supposed to do with this?

Five types of Quicksand Meetings you don't want to be scheduling

The Eternal Standing Meeting

The Fire Drill

The Big Room

The Chain Meeting

The Marathon Meeting

Five steps to avoid Quicksand Meetings:

That seems like a lot for my little meeting

Hat tips

1. Engineers in the codebase

2. Engineers leveraging the codebase

3. People understanding the codebase at a high level

4. People using the product built on the codebase

Putting it all together

1. Your organization does not need very many senior (Staff+ level) ICs