Personal city guides

I’ve seen lots of sites about how to use software. The Setup and The Sweet Setup are my favorites. You can find lots of sites about how to use ideas like Inbox Zero or Crossfit. People love this stuff.

What I don’t see a lot of is how to use a city, as a visitor or resident. I suspect these things are all around me and I don’t even notice.

A travel guide will tell you where you can go and what you can do, but it won’t tell you how you should go about it. It won’t tell you the little things you’d do as a resident but wouldn’t notice as a traveler. They don’t tell residents (or future residents) what the essence of the city is and what you should do when it’s nice, or gloomy, or when you want to go out, or when you’re hungry.

For example, if I had to write an Austin Setup guide, it would include things like:

  • what to eat lots of (tacos and breakfast) and what to eat little of (Italian, oddly enough)
  • where to go when it’s nice outside (S. Congress, Auditorium shores, or Zilker park), where to go when it’s blazing hot (Barton Springs), or where to go when it’s miserable outside (one of the many great coffee shops)
  • where to find funny people and where to find technology people (because those are my scenes)

The thing is, this would end up reflecting my idioms. Not as useful for someone who wants to do sports, or outdoorsy activities, or music. This thing is more personal, like an interview on The Setup about how people use computers to do their cool thing. Sort of a “how I’ve hacked my city to work better for me” guide. A reverse travel guide of sorts; not for everyone else, just for me.

Universes from which to source test names

A silly bit of friction in writing good tests is coming up with consistent, distinctive names for the models or object you may create. Libraries that generate fake names, like Faker, are fun for this, but they don’t produce consistent results. Thus I end up thinking too hard.

Instead, I like to use names from various fictional-ish universes:

Hopefully my teammates enjoy these little easter eggs as much as I enjoy looking them up when I need something fancier and less dry than metasyntactic variables.

You should practice preparatory refactoring

When your project reaches midlife and tasks start taking noticeably longer, that’s the time to refactor. Not to radically decouple your software or erect onerous boundaries. Refactor to prepare the code for the next feature you’re going to build. Ron Jeffries, Refactoring — Not on the backlog!

Simples! We take the next feature that we are asked to build, and instead of detouring around all the weeds and bushes, we take the time to clear a path through some of them. Maybe we detour around others. We improve the code where we work, and ignore the code where we don’t have to work. We get a nice clean path for some of our work. Odds are, we’ll visit this place again: that’s how software development works.

Check out his drawings, telling the story of a project evolving from a clear lawn to one overwhelmed with brush. Once your project is overwhelmed with code slowing you down, don’t burn it down. Jeffries says we should instead use whatever work is next to do enabling refactorings to make the project work happens.

Locality is such a strong force in software. What I’m changing this week I will probably change next week too. Thus, it’s likely that refactoring will help the next bit of project work. Repeat several times and a new golden path emerges through your software.

Don’t reach for a new master plan when the effort to change your software goes up. Pave the cow paths through whatever work you’re doing!

Sometimes it’s okay to interrupt a programmer

I try really hard to avoid interrupting people. Golden rule: if I don’t want interruptions I shouldn’t impose them on other, right? Not entirely so.

Having teammates around, and interrupting them, has saved my butt. I’ve avoided tons of unnecessary work and solving the wrong problems, and that’s just the last week!

Communicating with others is a messy, lossy affair. We send messages, emails, bug reports with tons of partial context and implicit assumption. Not (always) because we lack empathy or want to bury ideas in unstated assumptions, but because we’re in a hurry, multitasking, or stressed out.

When you interrupt a co-worker you can turn five minutes of messages back and forth to thirty seconds of “Did you mean this?” “Yeah I meant that!” “Cool.”

When you interrupt a co-worker you can ask “this made sense but you also mentioned this which didn’t entirely make sense” and they can say “oh yes because here’s the needle in the haystack” and now you can skip straight to working with the needle instead of sifting through the haystack that was your own assumptions wrongly contextualized.

If your coworker is smart, they are keeping track of why people interrupt them. Later they’ll try to make it easier for you to not interrupt them, e.g. write documentation or automate a task. Maybe they want you to interrupt them so that whenever someone wonders “why haven’t we automated this?” they can talk to you about how it’s important to have a human hand on it rather than let failed automation go unnoticed.

There are plenty of reasons not to interrupt someone. I know the struggle. I do my best to respect when people put their head down to concentrate and get stuff done. I always spend a few minutes rereading communications or spelunking the code, logs, or whatever context I have before interrupting someone. It’d be rude to interrupt before I even started trying. But, there’s a moment when the cost and benefit of interrupting someone so I can get something done faster swings towards mutual benefit. That’s when I interrupt them.

Let’s not refer to Ruby classes by string

I am basically OK with the tradeoffs involved in using autoloading in Rails. I do, however, rankle a little bit at this bit of advice in the Rails guide to developing engines.

Screencapture from Rails Guide to Engines
Screencapture from Rails Guide to Engines

In short, when configuring an engine from an initializer, you’re supposed to protect references to autoloaded application classes (e.g. models) by encoding them as strings. Your engine later constantizes the string to a class and everything is back to normal.

A thing I am not OK with is “programming with strings”. As an ideal, strings are inputs from other machines or humans and internal references to code are something else. In Ruby, symbols fill in nicely for the latter. Could I refer to classes as Symbols instead of Strings and live with the tradeoffs?

Well it turns out, oddly enough, that Rails is pretty sparing with Symbol extensions. It has only 120 methods after Rails loads, compared to 257 for String. There are no specific extensions to symbol, particularly for class-ifying them. Even worse (for my purposes), there isn’t a particularly great way to use symbols to refer to namespaced classes (e.g. Foo::Bar).

But, the Rails router has a shorthand for referring to namespaced classes and methods, e.g. foo/bar#baz. It doesn’t bother me at all.

In code I have to work with, if at all possible, I’d rather refer to classes like so:

  1. Refer to classes by their real ClassName whenever possible given the tradeoffs of autoloading
  2. When autoloading gets in the way, refer to things by symbols if at all possible
  3. If symbols aren’t expressive enough, use a shorthand encoded in a string, e.g. foo/bar#baz
  4. … (alternatives I haven’t thought of yet)
  5. Refer to classes by their full string-y name

But, as ever, tradeoffs.

They’re okay political opinions

The downside to the Republicans proposing a healthcare bill is that it’s a major legislative disappointment, given they’ve spent seven years symbolically opposing healthcare. The upside is that, at least, we have something substantive to discuss about healthcare. The silver lining is possibly voters will come to see the Republican party for its cynicism.

What is there to talk about? We could start with David Brooks on how we got to the point wherein the GOP has received their moment in the sun. He argues that neglecting three ideas led us to the propaganda of the Trump era:

First, the crisis of opportunity. People with fewer skills were seeing their wages stagnate, the labor markets evaporate. Second, the crisis of solidarity. The social fabric, especially for those without a college degree, was disintegrating — marriage rates plummeting, opiate abuse rates rising. Third, the crisis of authority. Distrust in major institutions crossed some sort of threshold. People had so lost trust in government, the media, the leadership class in general, that they were willing to abandon truth and decorum and embrace authoritarian thuggery to blow it all up.

Brooks argued Obama should have addressed these crises, which the ACA arguably did for the second. IMO, Republicans stoked all three of these fires while pointing their fingers elsewhere. Supply side economics built the first crisis, privatization the second, and propaganda media the third.

Meanwhile in Congress, Paul Ryan is rolling up his sleeves and saying taking healthcare away from Americans is about giving them freedom. Paul Ryan’s Misguided Sense of Freedom:

…But Mr. Ryan is sure they will come up with something because they know, as he said in a recent tweet, “Freedom is the ability to buy what you want to fit what you need.”

He went on to argue that Obamacare abridges this freedom by telling you what to buy. But his first thought offers a meaningful and powerful definition of freedom. Conservatives are typically proponents of negative liberty: the freedom from constraints and impediments. Mr. Ryan formulated a positive liberty: freedom derived from having what it takes to fulfill one’s needs and therefore to direct one’s own life.

(Positive and negative freedom, as terminology, always confuse me; this bit is well written!) This op-ed makes a nice point: healthcare as envisioned by Obamacare, and other more progressive schemes, imagine an America where we are free from worrying about health care. Preventative care happens because we needn’t worry whether we should spend the money elsewhere or take the day off. Major health care events like pregancy or major illness are only intimidating because they are life events, not life-changing unfunded expenditures.

I cannot understand why, outside of deep cynicism of the American dream, Republicans in Congress would not want this kind of free world.

A little PeopleMover 💌

A little PeopleMover 💌

I love the Tomorrowland Transit Authority PeopleMover. It’s what a transportation system should be.

People Mover Disney World
People Mover entrance, overlooking Main Street and the Cinderalla Castle, overlooking Tomorrowland

Outside but covered. Elevated so pedestrians can pass below it. Passing in and out of nearby structures. Couch-like.

People Mover Disney World
The People Mover over Test Track and Space Mountain

Futuristic but achievable. Doesn’t isolate people from each other. You’re one of my favorites, People Mover.

Your product manager could save your day

I thought the feature I’m working on was sunk. An API we integrate with is, let us say kindly, Very Much Not Great. Other vendors provide an API where we can request All The Things and retrieve it page by page. This API was not nearly so great, barely documented, and the example query to do what I needed didn’t even work.

Sunk.

Luckily, only an hour in, I rolled over to the product manager and asked if it was okay if we were a little clever about the feature. We couldn’t request All The Things, but we could request Each of The Things that we knew about. It wasn’t great, but it was better than sunk.

The product manager proceeded to tell me that was okay and in fact that’s kind of how the feature works for other APIs too. I hadn’t noticed this because I was up to my neck in code details. She described how this feature is used in out onboarding process. It wouldn’t matter, at that level, whether we made a dozen requests or a hundred.

I wrote basically no code that day. Someone who “crushes code” or “moves fast and breaks things” would say I didn’t pull my weight. Screw ’em.

I didn’t go down a rabbit hole valiantly trying to figure out how to make a sub-par API work better. I didn’t invent some other way for this feature to work. My wheels were spinning, but only for a moment.

Instead, I worked with the team, learned about the product, brainstormed, and figured out a good way forward. I call it a very productive day.

Three Nice Qualities

One of my friends has been working on a sort of community software for several years now. Uniquely, this software, Uncommon, is designed to avoid invading and obstructing your life. From speaking with my Brian, it sounds like people often mistake this community for a forum or a social media group. That’s natural; we often understand new things by comparing or reducing them to old things we already understand.

The real Quality Uncommon is trying to embody is that of a small dinner party. How do people interact in these small social settings? How can software provide constructive social norms like you’d naturally observe in that setting?


I’m currently reading How Buildings Learn (also a video series). It’s about architecture, building design, fancy buildings, un-fancy buildings, pretty buildings, ugly buildings, etc. Mostly it’s about how buildings are suited for their occupants or not and whether those buildings can change over time to accommodate the current or future occupants. The main through-lines of the book are 1) function dictates form and 2) function is learned over time, not specified.

A building that embodies the Quality described by How Buildings Learn uses learning and change over time to become better. A building with the Quality answers 1) How does one design a building such that it can allow change over time while meeting the needs and wants of the customer paying for its current construction? and 2) How can the building learn about the functions its occupants need over time so that it changes at a lower cost than tearing it down and starting a new building?


Bret Victor has bigger ideas for computing. He seeks to design systems that help us explore and reason on big problems. Rather than using computers as blunt tools for doing the busy work of our day-to-day jobs as we currently do, we should build systems that help all of us think creatively at a higher level than we currently do.

Software that embodies that Quality is less like a screen and input device and more like a working library. Information you need, in the form of books and videos, line the walls. Where there are no books, there are whiteboards for brainstorming, sharing ideas, and keeping track of things. In the center of the room are wide, spacious desks; you can sit down to focus on working something through or stand and shuffle papers around to try and organize a problem such that an insight reveals itself. You don’t work at the computer, you work amongst the information.


They’re all good qualities. Let’s build ’em all.

I have become an accomplished typist

Over the years, many hours in front of a computer have afforded me the gift of keyboarding skills. I’ve put in the Gladwellian ten thousand hours of work and it’s really paid off. I type fairly quickly, somewhat precisely, and often loudly.

Pursuant to this great talent, I’ve optimized my computer to have everything at-hand when I’m typing. I don’t religiously avoid the mouse. I do seek more ways to use the keyboard to get stuff done quickly and with ease. Thanks to tools like Alfred and Hammerspoon, I’ve acheived that.

With the greatest apologies to Bruce Springsteen:

Well I got this keyboard and I learned how to make it talk

Like every good documentary on accomplished performers, there’s a dark side to this keyboard computering talent I posess. There are downsides to my keyboard-centric lifestyle:

  • I sometimes find it difficult to step back and think. Rather than take my hands off the keyboard, I could more easily switch to some other app. I feel like this means I’m still making progress, in the moment, but really I’m distracting myself.
  • Even when I don’t need to step back and think, it’s easy for me to switch over to another app and distract myself with social media, team chat, etc.
  • Being really, really good at keyboarding is almost contrary to Bret Victor’s notion of using computers as tools for thinking rather than self-contained all-doing virtual workspaces.
  • Thus I often find I need to push the keyboard away from me, roll my chair back, and think, read, or write to do the deep thinking.

All that said, when I am in the zone, my fingers dance over this keyboard, I think with my fingers, and it’s great.