Adventures In iOS Automation: Middleman Blogging Edition

My Things site is built on Middleman, a static site generator that's pretty much the Jekyll modern people can love.

I've tried static site generators a few times in the past, and the thing that's always stopped me from adopting them full-time for my regular blog (this one) is the overhead of maintaining something built around Git on a bunch of devices when most of my writing is spontaneous and squeezed in around the edges of other stuff. I was willing to do it with Things because it's a slower site, and the bulk of the content is developed over days or weeks.

When I got the iPad Pro I'm typing this entry on, it made me start thinking about the things I'd like to be able to do given a closer-to-real keyboard and enough screen real estate to keep my brain from freezing up when starting at everything through a 10" window. “Create and post content for a website managed by a static site generator kept in a Git repository” seemed like a pretty good test case.

Attempt 1: Paleo

Reader, my formative Internet experiences all happened on a Lear-Siegler ADM-3A+ talking to an Ultrix machine over a 300 baud modem. Consequently, when I'm confronted with a “move text from one place to another and make things happen” problem, the first place I go to is “open up a dumb terminal to some distant end where all the brains and guts are, and go from there.”

To that end, my first cut at the “maintain a version-controlled static site from an iPad Pro” problem was to find a decent terminal app and see what I could do with it. I went with Panic's Prompt, which is simple and pleasant.

I went through the hassle of setting up rbenv on shared hosting, added a few conditionals to my heretofore-mac-only .emacs.d, and applied myself to creating a blog entry. The stuff in the Middleman workflow that involves running shell commands worked fine, which solves the most potentially labor intensive part of making a new blog entry, which is creating a file in the right place with the right starting content and a decent slug.

Sadly, Prompt and Emacs don't exactly get along. Most frustrating is that the iPad Pro Smart Keyboard doesn't even have an escape key, and Prompt doesn't seem to have any provisions for remapping opt or cmd to work as a meta key. Instead, you can opt to have it keep a soft keyboard up on the bottom of the screen and reach up to tap an ESC key. This is as awful as it sounds.

Attempt 2: Whatever the Kids Are Doing These Days

So, the way my brain works, I usually end up deciding if something that worked well for me 25 years ago isn't working now, it's probably time to swing to the other extreme. That led me to Workflow, which is probably the closest iOS is going to get to Automator any time soon.

Workflow is pretty cool: You can drag and drop actions from a variety of iOS apps and chain together workflows. It can assign and modify variables, munge text, pass text off to other things to be munged some more, and create little Workflow applets you can launch from your home screen.

So, I set out to solve the first problem of creating a Middleman blog entry, which was the part where you set a title and then pass it through a few actions to create a decent slug. In other words, you want to start from a title of “This Is My Fantastic Blog Entry!” and end with a permalink that looks more like: 2016-04-23-this-is-my-fantastic-blog-entry.html.markdown.

Given the ability to write a script, the things you need to do to get there are pretty simple :

  • Grab the title
  • Downcase it.
  • Strip out all the non-word characters and replace them with dashes.
  • Make sure there are never multiple consecutive dashes.
  • Make sure there's not a trailing dash (because it's ugly).
  • Tack on the date to the front.
  • Tack on “.html.markdown” to the end.

There are things you can toss in there: For instance, since you know you need a particular date format for the “date” field of the entry, you can stash today's date in a variable for reuse. Same with the pre-munged title.

Doing that on Workflow was easy enough, but laborious: Workflow itself doesn't understand regular expressions, so it has to go talk to a third-party app that does. Since that app is a single-tasking marvel, it can't pass an input string through several transformations then pass it back: It has to receive the text, do the first transformation and pass it back to Workflow, which then decides what to do next and passes it back. Workflow and that outside app do this little dance four times. Because all of this is being done with a fascinating grassroots-driven system of callback URLs the assorted apps all understand, you sit there watching Workflow switch back and forth between apps. It can be a little dizzying.

This is going to sound weird, but that rapid flipping around between apps made me sort of hate what I cobbled together, which stopped me from going to the next logical step, which was figuring out how to hand the thing my workflow stitched together back to something that could try to get it into a Git repo.

The Editorial Way

Since I'm a compulsive iOS text editor experimenter, I had a copy of Editorial sitting around. Editorial understands Markdown, and it has some built in automation you can use to create text filters and talk to other apps. While I have no doubt that Workflow is amazing for a number of things, starting from your text editor and handing off to something else seems more elegant than starting from a different app, scurrying around between all the other apps, and then handing off to something else.

With Editorial, you just stack up actions in workflows using a drag-n-drop visual interface. It can do regular expressions, transformations, ask for text, etc. There's a very nice custom UI builder that I want to try out, which would allow me to pop up a form with fields for the title and tags, or logic for whether a file is ready to be published or just a draft. You can bind a given workflow to a hotkey, meaning it's possible to just type up an entry in (syntax-highlighted) Markdown, hit a hotkey, and constitute a proper Middleman blog entry with slug that can be handed off to a receiving app.

A little Googling yielded a Jekyll-based workflow someone had already put together that got me most of the way to where I wanted to be. It didn't do real slugs, and its front matter was a little different, but it was a simple matter to modify and produce my own

Getting It to GitHub

The other half of that workflow involved getting the newly created entry over to my Middleman site. For that, it uses an iOS Git client called Working Copy. Working Copy is free if all you want to do is browse your repos, and it costs $14.99 if you want to be able to push to them. Like Workflow, it's aware of callback URLs, so it's possible to push things into it from other apps.

Once the file is in Working Copy, you can just commit it and push it. Done.

Building the Site

Well, not quite. I wanted to automate the last mile, as well: Not only did I want to get the content into the repo, but I wanted to be able to update a local copy on my shared hosting and then run a site build.

I got a little lazy here. There's a simple PHP script you can ping with a GitHub webhook that will do the work of updating a local copy. It's not a perfect fit, but it does what I need. I stuck it off in a corner of one of my live sites. A cron job handles running a Middleman build every few minutes. Since Middleman is pretty smart about looking for changed files, it's not as expensive as a comparable Jekyll build.


Anyhow, lots of things thrown out. If you're a static site blogger looking to use an iPad or iPad Pro to write entries or maintain your Git-based site, here's the basic workflow:

Please be considerate of my neighbors

So, here’s a scenario to try on:

You’ve just woken up in your tent down on the Springwater Trail.

You climbed into a sleeping bag the night before. The temperature was headed down to the low 40s. You’re sleeping in a tent among dozens of others in a similar situation. The small ad hoc community around you has all sorts, including  people who seem angry all the time, and young men who are dressed much more nicely than everyone around them. They don’t spend the night: They just make a few deals and then head home for the evening.  If you’re a woman, there’s a better than even chance you were assaulted within 72 hours of beginning your life outdoors. Since it’s April in Portland, it’s muddy and wet. You might have gone to sleep to the sounds of people fighting or yelling at each other. You probably woke up because it’s really goddamn cold, or because your children woke up with the light, the way little kids do. 

So, about the time you’re unzipping your tent, grateful that nothing happened to it or you or maybe your family the night before, a pair of people on expensive bicycles, all kitted out, ride by. They look around at all the tents, and one looks to the other and says “Jesus Christ, this is fucking disgusting.  Who the fuck are these people?”

Well, friend, they’re my neighbors. I ride by them every morning on my way to work, and again on my way home each evening. I’ve got a pretty simple protocol for making my way through the little community that has sprung up on the Springwater near 82nd. I’ll list some of its key elements:

  • I slow down. There are a lot of people down there, including families with small children. Nowhere I need to be is more important than any of those people. 
  • I don’t gawk or comment if I’m with someone. I wouldn’t want to be gawked at if I had to live in a tent along a trail. I wouldn’t want someone to loudly wonder “who the fuck” I was, or comment on my “fucking shithole” accomodations. 
  • I say “good morning” or “good afternoon” to the people I do make eye contact with.  That’s my practice with just about everyone I pass on the trail. 

I’d really like to believe that the “Jesus Christs” and “who the fuck are these peoples” are coming from a sense of deep moral outrage that we live in a country where families with little children, the working poor or anyone else for that matter has to live in a tent in the mud along a trail on the edge of town. Because I read and the Facebook groups for my neighborhood, I know that’s not always the case. At least sometimes they’re also coming from a place of deep revulsion with the people in those circumstances themselves, and from a deep desire to erase them from awareness … to push them out of view with no regard for where that might be or what it might mean for them. It comes from a place of rationalizing the existence of that kind of misery that comes from ones own precarity (though maybe that’s not so true of the people on the nice bikes out for a pre-work ride). 

Wherever it’s coming from, I’d really appreciate it if you’d keep it to yourself next time. Those people are my neighbors and I want you to be kind to them. 

Priorities v0.6

I got to spend a few hours on Priorities over the weekend. I put one thing back that the older app had, and added something new.

The thing that went back in was a conception of “effort” and a calculated combination of “effort” + “support” that yields something I’m calling “burden” internally, and “cost” in the UI. I could change it to one or the other, but I haven’t made up my mind which I like better, so I’m keeping it that way so the sense of misalignment will eventually spur me to a decision.

The idea of “effort” and “cost” is to capture the idea that not all goals take the same amount of work. By adding up the effort expended to work on the goal, and the level of relative support it’s getting, you can reflect a sense of what it actually costs to work on that goal.

The new thing I added is a little dashboard for goal health on each user’s home page:

Goals status

It’s just a simple tally of the number of goals in each state of health (good, medium, poor, unknown). If you’re using Priorities with other users who’ve shared lists with you, the tally shows up in your “Shared” list of lists, as well.

I guess there’s one other change: I’m assuming postgres for the app db in all environments. There are instructions in the database.yml file for how to set up sqlite as the db backend if you’d prefer that.

Source, as always, is up on GitHub. I’m also hosting a version I’m happy to share with others. Feel free to ping me if you’d like to learn how to get a login.

Priorities v0.5

Oh, feature creep.

So, last I wrote about it, I’d put together this little prioritization tool based on some thinking I’d done about priorities. I reused a bunch of code from a previous project to get to a sort of “good enough” state.

Then I started thinking about the ways you could extend that model into a bigger environment, like a company, which has several organizational levels besides “teams.” So I did a huge cleanup of the legacy code in Priorities and started work on something that would be more appropriate to modeling goals in a really large environment.

In the end, though, I realized a few things:

  1. I don’t really own that other project anymore. I mean, it’s “mine,” but I’m sharing it with people who’d like to do more with it.
  2. The places I was taking that other tool were being shaped by the company I work for.
  3. The thing I set out to do with Priorities was meant to be really simple. There are ways to extend the idea, but they leave the tool in a place where it’s harder to approach for someone who isn’t working in the same company as me.

So this weekend I just started over with Priorities. Since I’d been working on an alternate app that needed a bunch of the old Priorities code cleaned up, I had a pretty decent set of models and templates, so it was really easy to reuse a lot of the thinking, but keeping the new version to something quite simple.

The older version of Priorities, the one I wrote from all the legacy code, lives in its own branch now, since I learned at least one person had downloaded it and was using it.

The new version is in a new master branch on the project. For this version, I did a few things:

I changed the “Team” model to “Lists.” Not everybody’s managing a team. You can still name a list after a team, or whatever you like, but by talking about “lists,” it’s more of a tool for anybody, from a sole proprietor to a company.

I also began working toward making lists private. The old version let everybody see everybody else’s lists. The new version will still allow that, but you have to go looking. Once I get the basic features polished up, I’ll take a pass back through to require ownership to view a list. Once that’s done, I’ll work on allowing owners to set their lists to be public. For now, the app guides you toward just looking at your own stuff.

There’s a little help if you’re a new user and don’t have any lists set up:

Priorities Home

There’s also a prompt once you make a list and don’t have any goals:


If you’re interested in giving it a spin, you’ll need Ruby and Bundler on your system:

  1. sudo gem install bundler (no sudo if you’re using rbenv or rvm)
  2. Download Priorities from GitHub: git clone
  3. In the download directory, install the needed gems: bundle install
  4. Set up the database: bundle exec rake db:migrate
  5. Run the app: bundle exec rails s
  6. Visit the app in your browser.

Since it’s running in dev mode, it’s going to be sort of slow on load.

The TODOs are pretty simple at this point:

  • Do more to ensure the privacy of individual lists.
  • Clean out the remnants of the old team model.
  • Put it somewhere private but not secret so people who don’t want to run their own instance can use it.

Then there are a few things to think about:

  • Adding info pages for each goal.
  • Adding notes for each goal.
  • Adding back the comparison data for goals.
  • Figuring out if there’s value in expanding the user model to have “groups” for shared lists.

Priorities v0.01

I spent a chunk of yesterday and a few hours today pulling a bunch of plumbing out of the Docs Decomposer so I could remake it into what I’m going to just call Priorities.

It’s a tool that lets you step through the prioritization exercise I outlined yesterday, and it provides a few extras because it’s happening in the context of a dynamic web page.

The Docs Decomposer had a prioritization tool bolted on as an afterthought, so it was missing a few things, including a conception of “teams.” Priorities has a Team model that allows multiple teams to exist inside of it, each with their own members and lists of priorities.

It’s in a somewhat usable state now, to the extent you could check it out of GitHub, run bundle, run the migrations, and self-provision your account, team, and priorities. The workflows for some of this aren’t great, and a few of the relationships that are meant to be two-way are as yet one-way. I think its documentation page is still that of the Docs Decomposer’s, too, so it won’t be super helpful.

Here’s a quick demo of the basic use:

There are a few places I’d like to take it:

Teams have but a single flavor now. Making the tool think of teams in terms of scrum teams or services teams would make it easier to extend Priorities into a general purpose prioritization and auditing tool. Services managers, for instance, could have a dashboard where they characterize the level of support they’re offering each scrum team, or would have mandatory priority objects for each scrum team the app knows about.

I’ve temporarily removed the tying of users to priorities. It would be easy to put them back, but the current approach to that problem assumes everyone on a team would be an active user of the app. People shouldn’t have to have logins to review team priorities. If I can solve how to do that, then active users can start having their own user pages, where they can see efforts they own and perhaps contribute to reporting around the priorities they’re responsible for.

The organizational model is flat. Extending the models to include a conception of “organizations” and adding some notion of whether a priority is tied to (or is) something like an OKR would make it possible to model an entire company.

Anyhow, next steps probably ought to be:

  • Cleaning it up under the hood a little.
  • Finally delivering on better user password reset tools.
  • Figuring out what it takes to Herokuize it.

Thinking About Priorities

I’ve had to think about prioritization a lot over the past few years. A few things make prioritization hard, even if you know you need to do it:

If you’re a manager in a busy place with a lot of customers or partners, you might have lost track of all the things you’ve committed to. If you don’t have a good practice of recording outcomes and next actions in meetings, you’ll find things creeping around behind your back.

If you don’t maintain boundaries with customers or partners, it’s going to be an issue for you, too. If you’re the type who’s open to being grabbed in the hall and put up to something on the basis of a nodding agreement, or if you regularly let people outside your team head straight to people who report to you without checking in on the interaction later, you’re not really maintaining boundaries.

If you and your manager or you and your team don’t have a culture of requiring a conversation about priorities with each new commitment, prioritization will be difficult.

If these patterns look familiar to you, you probably also know some of what comes next:

Your team will start to run hot as they struggle under the load of an undifferentiated (and possibly incomplete) list of their deliverables. That will take the form of stressed out behavior and guilt over what’s not being done. The folks with a workaholic streak will double down on their effort and become frustrated with people on the team who don’t follow suit. The ones who aren’t going to be pushed into working past reasonable hours will go into a defensive crouch.

Lacking a way to talk about your priorities with customers or partners, it’ll become easier and easier to flip from a posture of relative openness and helpfulness to one where it’s simpler to just say “get back to me in six months” (or never, if you’re being honest).

You’ll begin to focus on headcount as the cure to your problems: You know enough to know you’ve got a ton on your plate, and that your team’s morale is beginning to suffer, and that a few extra hands could at least take some of the pressure off.

Looking back, I don’t think I’ve ever worked anywhere that was doing a great job with prioritization, to the extent “great” would mean you’d be able to get affirmative answers to all these questions:

  • Do the managers have a list of everything they’ve committed to?
  • Is that list prioritized to at least the level of high/medium/low/not, and is it shared with everyone on the team?
  • Do managers periodically reassess the list and clearly identify things that can fall down into the “not a priority” bucket?
  • Do people on the team feel empowered to ask about the relative priority of new things as they come in without being made to feel like that’s an insubordinate or unfair/gotcha question?
  • Does everyone on the team treat those priorities as real?

Consequently, just about everywhere I’ve worked has shown some of the symptoms of poor prioritization, too. The ones that bother me the most are guilt and recrimination.

Guilt affects peoples’ ability to be open and honest about their work, and it erodes a team’s ability to celebrate what it has accomplished. Guilt also eventually blocks people from being able to ask for what they need from others, because the person feeling the guilt worries that they’ll be viewed as a hypocrite when they have their own impossible list of unfulfilled obligations.

Recrimination — anger turned on teammates for not doing enough — destroys trust, makes it hard to get people to pull together, and creates a toxic environment.

Taken together, guilt and recrimination from poor prioritization will grind a team down.

A Prioritization Exercise

I don’t think I’ve ever felt the challenges around prioritization more acutely than at a startup, where there’s a huge amount of energy, a massive appetite to solve big problems, and a desire to buckle down and become profitable (which means the “toss a few more bodies on the problem” solution to poor prioritization is losing its currency).

After some painful and frustrating conversations around the work my team was doing and the hands we had available to do it, I did an exercise that helped a lot.

The goal of the exercise is to get everything you’ve got going into a list, figure out how important each of those things is to you, describe how much effort you’re putting into it, and then start figuring out what really matters and what needs to come off.

The exercise uses a very simple model that helps you see the gaps between the priorities you think you have, and the work you’re actually doing.

Once you’ve completed the initial steps, you’ll have something that can serve as the foundation of a conversation with your team and your manager, as well as a tool to build an ongoing practice of thinking about what’s important and how what you’re actually doing lines up with that.

There’s no real magic here. The thing that strikes me about this process, however, is that when I describe it to people and show them the tools I use, it strikes a nerve. I think a lot of people are used to carrying their priorities in their heads, or expect their manager or some other leader to let them know what their priorities are (and steer them back when their actions don’t line up with priorities). So I’m writing about it in the hopes that people who are struggling with the stuff they have to do will see something they can use (or modify, or at least get some inspiration from).

This is also written from the perspective of someone managing one or more teams. If you don’t manage anybody, you can still run through this exercise with the projects and tasks you’ve been given.

I’d recommend you do this using a spreadsheet: You’ll want ways to sort the information you gather for the exercise. I wrote an app to help me with it, and I’ll share a little about that in an upcoming entry.

1. Make Your List

If you’ve ever tried to do the Getting Things Done approach to task management, you know that one of the first things you’re supposed to do is get everything out of your head and into a list. That can go a long way to helping you feel less overwhelmed right away.

What goes onto the list is going to vary by the kind of work your team does. Since I manage services organizations, I tend to break the team’s work down into these areas:

  • Customer commitments: The teams and projects we’re supporting.
  • Professional practices: The actions we layer on top of the basics. For a writing team, for instance, it might involve multi-stage editing.
  • Team maintenance: Things the team does to maintain itself, e.g. professional development, maintaining and developing tools and processes, etc.

You definitely want to include the things you’re doing or have committed to do. You should also include the things you want to do but have no current plans for, and things you’ve recently refused to do.

It might be helpful to add a column listing who on your team is working on what. Who you’ve put on a given task is an implicit comment on its importance to you.

2. Prioritize Your List

Once you’ve got your list, prioritize it. That doesn’t mean you need to force rank everything. Aim for a simple high/medium/low/not scale. Don’t try to come up with some formula for how much of your list should be at a given priority: That’s overthinking it, and you’re going to address that soon enough, anyhow.

If you’re using a spreadsheet, using numbers for your priorities is a good idea. I’d recommend a 0 = none to 3 = high scale, because you can do math on this a little later on. For instance:

  • 0 = No priority at all. You know it’s a thing but you don’t have any plans to do anything about it any time soon.
  • 1 = Low priority. This is something that would be nice to have some day, and that isn’t at all necessary now.
  • 2 = Medium priority. This is something that requires at least some maintenance on your part as a secondary duty for someone, even if it doesn’t warrant your full attention. If it slips for a little while, it won’t cause too much pain, if any.
  • 3 = High priority. You have to actively work on this, either to build it or to maintain it to a high standard.

3. Qualify the Effort You’re Giving Each Priority

Once you have your prioritized list, you should take a look at each item and ask how much effort and attention you’re giving it. I’d recommend, once again, using a 0 = none to 3 = high scale.

There are a few ways to think about this number. Here’s a scale to consider:

  • 0 = The item in question is getting no effort at all. Nobody’s paying attention to it.
  • 1 = The item is getting very little effort. Someone — maybe not the same person every time — checks in on it now and then, there’s a long backlog of issues with it that are addressed irregularly. Quality may be relatively low.
  • 2 = The item is getting some effort. It has a clear owner but it’s not getting their full attention. Quality may be “best effort” as opposed to “high.”
  • 3 = The item is getting full effort. The person or people working on it are expected to prioritize it above other things, it consumes a significant portion of their time, and it’s being completed to a high degree of quality.

4. Think About the Disconnect Between Priorities and Effort

At this point, if you’ve got everything in your list prioritized and if you’ve recorded how much effort you’re putting into everything, you can do a little math that will help you think about the health of your priorities list.

You can assess the relative health of everything on your list by looking at the disconnect between your priorities and your actual effort. I call this “risk,” but “health” is fine, too. The main point is that you want to capture how wide the delta is between your stated priorities and the actual work you’re putting toward them.

A quick formula in your spreadsheet will do it:

item priorityitem effort = risk

  • Risk > 1: High Risk
  • Risk == 1: Medium Risk
  • Risk <=0 : Low Risk

You can use conditional formatting to make the calculated “risk” column a little easier to parse, as I did in this simple spreadsheet:

Priority Tables

I wrote a conditional formatting rule, btw, that catches things under ‘0’ and highlights them: That shows you where you might be putting more work than necessary into something of relatively low priority.

5. Talk About it With Your Team

At this point, you probably need to sit down with your team, put the spreadsheet up on the screen, and start talking through the work you’ve done so far.

This conversation is going to require a baseline of trust between you and the people on your team. If you’ve been having problems with poor prioritization, you’ll probably find that there’s a certain amount of guilt and defensiveness. Some people might be worried that you’re doing this work to document blame.

You need to make clear that you’re not using this exercise to place blame or judge people for what they’ve been doing. Rather, if prioritization has been a challenge for you, you need to own your own leadership gaps in this area. Explain that you’re looking for help to get a good picture of everything your team thinks it’s supposed to be doing, and to make sure you understand where relative levels of effort are going.

If you’ve got a few layers of management, you might want to keep this initial conversation to leads or managers, especially if you’re dealing with a demoralized team or one with a poor performer. You don’t want the “effort” question to devolve into one of individual performance. Rather, you want to have a clear idea of how much work is being done around a thing, good or bad.

For that reason, I’ve taken a stab at modeling and then shied away from things that look like story points. They just make people nervous and it slows down the conversation.

Things to ask the team include:

  • Is the list complete? Make sure you haven’t missed something, or mistakenly lumped a few things in together in a way that hides effort or complexity.
  • Is the amount of effort you recorded accurate? Sometimes you find that someone on the team has been putting a lot more into something than you realized. Alternately, you may discover something has been allowed to slide for months. Note those, move on, and if they represent a performance issue deal with them in a 1:1.

Once you’re done with this, you’ve got a snapshot of the team’s state you can use to drive conversations with your own manager.

6. Take It To Your Manager

Once your team has vetted your snapshot, it’s time to take it to your own manager for review. If you’ve got everything in a spreadsheet and have a little conditional formatting to help make it easier to scan, the conversation can go line-by-line:

  • Describe the item in question.
  • Explain why it has the priority it does.
  • Explain why it’s getting the level of effort it does.
  • Point to the calculated risk/health field and ask if it reflects an acceptable outcome for the item in question.

Your manager probably won’t agree with all your priorities, or the amount of work you’re expending on a given item. That’s great! You did all the work up to this point to make it easy to find those disconnects.

The thing you need to do, though, is think in terms of tradeoffs. If your manager wants to bump something up in priority or apply more effort to it, you should press them to explain which items you can back off on to shift capacity accordingly.

As you work through the list and make adjustments, take advantage of the spreadsheet: Sort by different columns to offer a picture of the things with the highest priority, or the things consuming the most time, or that are at most risk because of a disconnect between priorities and effort.

Once you’ve worked through the list, give it a final sort by the risk/health field, and take a hard look at the things you see as high risk/poor health. The questions you and your manager need to be asking at this point are:

  • Is this in an acceptable state right now?
  • Is there anything happening in the near term that might change this? (e.g. planned hiring that will provide more capacity)
  • Is this something we can drop to a lower priority, deprioritize altogether, or actually drop from the list?

7. Take It Back to Your Team

Once you’ve run through the list with your manager, identified misaligned priorities, made adjustments to priorities, and identified a plan to correct misalignments, make sure to close the loop with your team.

For each item that changed, talk about an action plan to make the needed adjustment. That might involve communicating with stakeholders, shifting work around on the team, or simply resolving to quit thinking about something for a while.

The main thing you want to do, though, is communicate a clear sense of permission for each thing that ends up getting less priority or effort. If you’ve been having problems with prioritization and people on the team are dealing with guilt over what they haven’t been able to do, let them know it’s okay to put those things down, that you support them in doing so, and that you’ll defend the team’s priorities and effort to your manager and the rest of the company.

8. Support and Maintain Your Priorities

Once you’ve been through this process, you have to support the work you did.

Review your list periodically: Once a month give it a look and think about each item. Once a quarter, pull your team back in and review. If things change and you need to reassess, bring it back up with your manager.

If you have some sort of progress/status reporting routine, ask everyone on the team to specifically report against the priorities on that list. They might not be doing everything on that list every week, but a section of their report should include things from that list. Work that wasn’t done against any of your priorities needs to show up in its own area because you’ll need to assess whether it was truly a one-off, or something that needs to go onto the list.

Make priorities part of your weekly 1:1s. You don’t want 1:1s to devolve into tactical discussions or 30-minute readouts, but a snapshot of the week’s priorities delivered in the first few minutes keeps everyone thinking in terms of what’s important.

Build a healthy practice of discussing priorities both on your team and with your own manager. If a new piece of work turns up, talk about its relative priority, discuss how much work should go toward it, and add it to the list so you can assess it against everything else you’re working on.

In Practice

I walked through a lot of this process earlier this year, after a bunch of frustrating conversations about headcount. My team had a long list of stuff accumulated over the years, with a section of that list simply falling off the bottom over and over, and we simply didn’t have the people we needed to do it all.

I’d already written an app that modeled who was on the team and the things they were working on at a low level (individual pages of documentation) so it was pretty easy to add a model for all the areas of concern we had and do a little work to make it present nicely.

I saw the benefits from taking this approach at several levels:

For myself, as the team’s manager, the act of getting everything into a list was so clarifying. I had other sources of truth for the work my team was doing, mostly in JIRA, but they weren’t as focused as the list.

For the conversation I had with my manager at the time, we had a way to interactively discuss our priorities and where the work was going. He ended up helping me find places where we’d been working to a higher standard than he felt was required, and provided me with some permission to offload some of that work to other teams. Some things came up in priority as a result of that shifted capacity, but we also ended up agreeing that more seniority on the team and an additional writer would help. Some things he’d put on me he realized he’d stopped caring about, and we dropped them.

For the team, it was helpful to see the results of that discussion. They could see that a constructive conversation was happening about their commitments, and that my manager and I had agreed some things weren’t sustainable at their current level of effort.

Priorities Farmers

It gave me an opportunity to express to them in very clear terms that the snapshot we’d described was something of a contract I’d honor.

One of the more senior people on the team said the hour or so that went into the initial review of priorities and the ensuing followup were the most useful meetings he’d been in, because they helped him finally understand the things he could stop worrying about after years of having them on a mental list.

Services orgs get a lot of incoming tickets telling them what they “should” be doing, and the people filing those tickets aren’t always mindful of the things they’re piling onto someone else’s plate. Having a prioritized list published somewhere that was easy to point to also made it a lot easier to educate people around the company about our work and priorities.

Finally, the exercise has been useful for having headcount conversations both up and down. When we recently had to consider trading some eventual headcount away in favor of a big overhaul of an aging toolchain, we had a source of truth to turn to. In the absence of a new team member, we had some stuff that was in a state of marginal or poor health that might have to remain that way. Was it worth it? We had a way to validate our hunch that it probably would be, and even a way to see the ways in which some things in the “no time soon” backlog would probably be helped along more by better tools than more people.

Next Steps

I’ve recently turned my attention back to that app I was working on. I spent some time over the weekend isolating the priorities model from the pieces specific to a tech writing team, then nesting those priorities inside a team model. That has all resulted in a much smaller, easier to maintain prioritization tool that can account for multiple teams.

With a little more work and a few more models, it will be able to support a multi-level organization. The ideal end state to me would be recording something like OKRs at a high level, then associating team-level priorities to those OKRs and modeling in health metrics.

For now, I’ll be content to get it to a point where it can be shoved out onto something like Heroku, where anybody could set up a single team and step through the prioritization exercise.

If you’re interested in playing with it, drop a line and I’ll either show you how to run your own instance, or give you an account on a stable machine once I’ve pushed it up to one.

Get-Right Saturday

At some point in my writing career — at some point around the time I was responsible for turning in a regular column on some real 101-level home networking and security topics — I came to a realization that was, as always, nicely encapsulated by an XKCD:

Realizing that was pretty liberating! Suddenly I wasn’t worried so much about whether what I was writing about was new or novel: My website wasn’t meant for people who needed constant novelty, and the people who were reading my columns were really just trying to make sense of the most basic stuff: How do I protect my new wireless network? How do I protect my privacy? When people talk about privacy and Google, what are they concerned about and should I be, too? How do I move this file from my desktop to my laptop?

Once I stopped writing the column and spent more time as an editor for my bullpen, I carried that along with me. My writers were all really smart, cutting edge sorts of people, and some of them would get wrapped around the axle trying to write about stuff that was new. But the audiences for all my sites were people who were coming to grips with technology and needed a confident voice to accomplish the basics plus some next-level stuff. So I’d coach the writers toward helping those people gain some level of conversance and basic mastery.

That’s all to go toward this particular blog entry, which is also sort of 101 stuff about life that I think I’ve figured out and maybe someone else hasn’t.


We recently adopted a practice we’re calling “Get-Right Saturday.” It works like this:

  • We have a recurring event set up in the family’s reminders list. It triggers at 10:00 on Saturday morning, and it goes to our phones, tablets, and laptops via the iOS/OS X Reminders app.
  • When the alarm goes off, we stop what we’re doing and spend 45 minutes or an hour picking up the house. Whatever pieces of mail got left on the table, or coats got draped on the kitchen chairs, or shoes that sort of shuffled away from the front door de-shoeing area get herded back to where they belong. We sweep, dust, vacuum, and clean the bathrooms. A load of laundry goes in the washing machine.
  • Once we get tired of doing all this, we each drift back to whatever we were doing (or I go upstairs and work on the bills for a few minutes) and get on with our weekend.

I mean, no big deal. Not groundbreaking.

The thing that made it a breakthrough for us was stopping to examine things that were frustrating us very deeply about our household each week, because of the way our lives work:

  • Al has a full-time job on the far east side. It’s a pretty engaging job with a lot of challenges.
  • Ben’s going to a school way outside our neighborhood, and he does after-school stuff that can keep him until 5 or 5:30. Since we have one car, Al handles carpooling Ben and a few other kids from the neighborhood down to SE Burnside in the 20s, then back out to her job on SE 120.
  • I’ve got a full-time job downtown. Since we have one car, I don’t have a lot of flexibility. I take the Max or I ride my bike, and my commute each way is pretty much an hour because I’ve got to either walk back and forth to the Max station, a mile from the house, or spend extra time changing/getting ready to ride my bike. Some days I’m up at 4:45 to make early meetings.
  • I’ve got a few other cognitive challenges that make it pretty hard to not fall into something and forget about all the other things, which is a polite way of saying my housekeeping habits have slowly improved over the years from “catastrophic” to “shambolic.”

I’m not complaining at all. Neither of us do. We both love what we do. In one way or another, each of our jobs is something of a cause. Ben getting to go to a school that’s better for him is more important to us than the convenience of being able to pack him on a bus each day.

At the same time, we have to prioritize. Keeping up the house slips over the course of the week. There’s homework to help with, our days to talk about, books to read, news to follow, and on and on.

I used to do a little more over the course of the week when I worked at home. It was easier to take small breaks to pick up, do a few dishes, run laundry through, etc. We lost that when I started working in an office again, got it back briefly during a regretful period of home employment last fall, and lost it again in November.

About a month ago, we noticed how irritable the clutter was making us, so we talked about it and figured it out:

We were both raised in houses where there was a full-time breadwinner, and another parent who wasn’t working full-time through most of our childhoods. One of us had a housekeeper, and the other a mom who was fond of chore charts and training the children to do dishes, pretty much setting herself up as the shop supervisor for a small housekeeping workforce of underage laborers.

So, our expectations were informed by our upbringings, and our upbringings were about single-income households where one of the parents could spend more time just keeping things up (or managing the children to keep things up, or making sure the housekeeper was keeping things up).

They were also informed by the people around us. We know all sorts of people, ranging from single-income households with children to dual-income child-free households. It’s natural to compare, and it bothered us that our house didn’t really feel “drop-in ready” most of the time. I mean, some of that’s the house: It’s got a relatively small open plan common area on the ground floor, and that’s where we spend most of our time. It doesn’t take much for that space to get out of control.

Our behavior toward the housekeeping was informed by the shape of our weeks. We’d get through the week, feel sort of greedy about our time to do whatever we had in mind for the weekend (which amounts to laundry, grocery shopping, getting haircuts, and going to movies), and we’d never really sync up on the stuff that was bothering us around the house.

That was making us both feel guilty, which was sort of a stupid way to feel given that our material conditions were different from the ones that created the measurements we were using to gauge our success at being grownups. It was also making one or the other of us pretty cranky about what wasn’t getting done.

Get-Right Saturday is great for a few reasons:

  1. The house has stabilized into a sort of baseline level of declutter that’s pretty good. Yeah, it drifts during the week, but we’ve beaten a lot of it back.
  2. When things do get a little out of hand during the week, we don’t get as anxious or guilty. We know we’ve got an hour of working on that coming up in a few days.
  3. We hold each other accountable to concentrate 3 people hours on the house.

That 10 a.m. start time gives us enough time to get up, get breakfast, and sit around reading or playing games for a little while before starting. When the hour’s over, we still have most of the day ahead of us to do whatever we were planning to do.

Like I said, probably not new to a lot of people, but maybe new to a few people.

Bonus Tip

We were also raised with what I’ve come to think of as “American-sized” laundry baskets. I don’t know the exact dimensions, but I can confidently say that each one holds 1.5 – 2 standard washing machine loads of laundry. If you’re the type who is visually cued to deal with laundry, and not the type to decide laundry day is actually a few days, American-sized baskets are the devil: They hold enough to mean you’re going to get into a couple of loads worth, which means laundry becomes a bigger chore by instance.

We recently decided we needed a few more sorting baskets for the laundry area, so on our next trip to Ikea we picked up some of their baskets. We noticed they were small when we bought them. Since they were meant as a sort of holding tank for laundry we wanted to get out of the way so each of us could play through the machines on the weekends, we didn’t mind that they weren’t meant to hold a standard North American laundry basket worth of stuff. We did kind of make fun of them, though, in an ironic way.

“These laundry baskets are fine for your Northern European social democracies and possibly Canadians, but they do not support our more expansive American needs.”

So, anyhow, what we discovered after two weeks was that the smaller Ikea baskets hold a single load of laundry. When one is full + 8″, it’s ready for the washing machine. That means laundry’s a lot simpler. Less stuff stacking up in the laundry area, because a single load is going through with each basket, not 1.5 or 2. You just see that you’ve hit capacity, drag it downstairs, shuffle the Ikea-sized load in the dryer into a basket, shuffle the Ikea-sized load in the washer into the dryer, stick your stuff into the washer, and it’s like the Island of Sodor or something in its balletic synchronousness.

I super recommend them if you’re the type who’s disciplined enough to respond to a basket that is visibly full, but not organized enough to simply do the laundry weekly without the visible reminder.

Writing About Things

I pushed v1 of a little project up to a new puddingbowl subdomain this evening.

Things is meant to scratch a few itches:

I’ve been meaning to redo this site as “a real site with a blog attached,” I’ve been wanting to not use WordPress anymore, and I’ve been wanting to write things that aren’t blog entries. Things only satisfies one of those criteria right now: It’s not WordPress. There’s not much content on it at all, and of what there is, one of the things is a repurposed blog entry.

Anyhow, here’s why I think I’ll like working on it:


I wanted to start writing reviews about things, and I wanted to try to do better than a lot of informal reviews I end up stumbling across when I’m trying to learn more about something. When I was trying to learn about standing desks a few years ago, I kept coming across all these reviews written from the perspective of someone who’d been using one for all of a week. That didn’t help me understand the products, and it really didn’t help me understand what you’re in for with a standing desk.

Reviews in general are kind of like that. I’m really thrilled when I come across one where the writer is circling back on their initial review months later, or simply hadn’t bothered to write about the thing at all until they’d had some time with it. Most of the time, though, you’re getting initial impressions. It’s that way from commercial sites because they’re under pressure to have those early impressions out. It’s that way for personal sites because people mostly seem to want you to know they have a thing, and they don’t often care to come back around and note that it was a bad purchase, or that it broke and they threw it out, or that they just don’t care to use it anymore.

So, the core of Things will be me trying to improve the situation for anyone considering purchasing a thing I happen to own and wanted to write about: I want to come back to each one I write later on and offer the long-haul perspective on it.

The reviews I write get a score based on how long I’ve owned a thing. So, for instance, my initial review of a Schwinn Loop folding bike—which I’ve owned for less than a month—gets a lower score than my review of the Quicksilver, which I’ve owned for just shy of a year. I could figure that out for myself and periodically update the site by hand, but it’d be better to automate that.

That’s where the backend comes in:


I was introduced to Jekyll as “a static site generator built on Ruby.” If you’re like me and maybe had several Rails projects behind you when you first heard that, you might think things like “oh, cool … I bet it uses ERB or maybe even HAML for templating!” and you got a little excited over that.

Jekyll very pointedly does not use Erb or HAML, and after almost three years of coming in and out of contact with it in a professional capacity, I don’t really want much to do with it in my spare time.

Middleman is a static site generator built on Ruby, and it does use HAML right out of the box, along with a few other pretty nice things. I’m having fun with it.

One of the ways I’m taking advantage of having HAML templating is in the review templates: I put the date I bought something I’m reviewing in the metadata of a review, and that changes the visual presentation of the review. So that Loop review has a red warning box, and the Quicksilver review is a sooting blue.


So, that’s that. The reviews (such as they are) are the featured content. I’d like to move some of my tool- and things-related blogging from here over to there, and I’d like to start building sections about tools I use a lot over time.

I also want to use what I’m learning building out little features here and there to redo this site. That’s gonna take some time because I don’t want to use somebody else’s pre-packaged theme.

That’s kind of what got me on this kick: The theme for this blog dates back to when Blueprint was the new hotness in CSS frameworks. Someone bundled it up for WordPress, I poked at it a little to personalize it, and here we are. I’d like to climb just one level up the ladder, to using Bootstrap and HAML to put things together. Still someone else’s CSS framework and all the rest, but it’s just a hair bit more I can play with.

There’s a Human Tooth Where ESC Used to Be, or: Playing With a Chromebook

We have this promotion going on at work where you can get a free Dell Chromebook if you buy a Linux training course. I got a sample of one of the Chromebooks and did a little writeup about putting a minimal Linux distribution on the machine via Crouton.

Crouton’s kind of neat: If you stick your Chromebook in developer mode, it opens up a minimal Linux environment you can further leverage to install a full Linux distro on the machine, side-by-side with ChromeOS. You can choose Debian, Ubuntu, or Kali.

My writeup was about Crouton’s two CLI environments, which let you run a “real” Linux without the overhead of a GUI. The Chromebooks are there to help you learn Linux so you can get a certification, and the certification testing is conducted in a command line environment: Might as well get used to it.

The initial writeup was supposed to be about booting the machine into Linux from an SD card or USB stick while retaining ChromeOS. This particular model doesn’t allow that, and there was the looming possibility of screwing up the instructions and bricking the machine; or, worse, doing a fine writeup of the process that would lead someone less careful to blithely brick their own machine. So I settled on “minimal CLI Crouton.”

Anyhow, a few thoughts:

Dell Chromebook 11 (Hardware)

It’s not bad! It weighs a bit over three pounds, has a comfortable, spill-resistant keyboard and a rubber bumper. It feels very sturdy and substantial.

The one thing I’m not a fan of is the 11″ display. I thought maybe it was me being spoiled by Retina displays, but it’s not: I compared it to an 11″ MacBook Air and it’s simply not that crisp. That’s exacerbated by Chrome/ChromeOS, which doesn’t have great type options and tends toward tiny type in the UI.

The keyboard is a little different from standard laptops. Google preferred to pretend function keys don’t exist, so you don’t see any “f1” etc. on the function key row. It’s all ChromeOS functions (forward/backward, reload, fullscreen, tile windows) and standard laptop controls (volume, brightness). On the other hand, those really are function keys. When you have the machine in developer mode, you can switch between ttys with them.

In lieu of a caps lock key, there’s a search key. In ChromeOS, it toggles a popup Google search/Chrome app launcher. There’s no command or Win key, either, so you get an extra large ctrl key. That’s a bit cruel to an Emacs user: ChromeOS uses the more Win-style “CUA” bindings, so I spent a day or two using that giant ctrl key to accidentally “select all” rather than going to the beginning of a line.

When I compare the machine to the ASUS eeePC I bought several years back, it’s very nice. The keyboard is superior, the machine is more rugged, there’s more RAM and storage, and 11″ of screen feels capacious compared to the 8″ the eeePC had. It’s way easier to imagine this machine filling the use-case I had in mind when I bought the eeePC, which was “portable text-editing rig.”


I was a skeptic going in, but I gave myself a few days to try it out, and I’m beginning to get it. I can’t honestly consider adopting a Chromebook as my sole machine, but I can easily imagine taking one along for business travel in a Google-centric work environment.

I think squeezing the iPad into work situations made me more amenable to the Chromebook. You have to adopt a certain minimalist mindset to deal with their respective UIs. Pick up that skill for one, you can slip into it with the other.

So by the end of a week with ChromeOS, I was “just working.” The basic Google apps don’t change at all. There are a few things you can have on a Chromebook that you might be used to on a desktop machine in one form or another. A few things I found:

  • There’s an Evernote app that works pretty well. I think it’s an Android app running on top of ChromeOS, so it doesn’t behave like a browser window. Drawback: Tiny type you can’t adjust.
  • There’s a web-based Markdown editor called StackEdit that’s really well done. It can save to Google Drive, GitHub, WordPress, and Dropbox. It has a live preview and different themes. I’d have no qualms using it on the road.
  • Skype and Slack have web apps that serve for the basics. Combined with Google’s chat app, I had a way to talk to everything in use at work.

I came to appreciate the limitations by the time it was all over. I could do just enough and not much more. We can take it as a measure of how much I liked it that I considered spending the computer allowance work gave me on a Google Chromebook Pixel. Knowing I could put Crouton on it to have a development environment was encouraging, but two things stopped me:

  1. Having a Chromebook in developer mode is a little inelegant. The manufacturer does not want you to do that, so every reboot greets you with a warning and you have this nagging sense that you’re an automatic update away from the stuff you did to build a Linux environment being taken away.
  2. I was able to actually play with a 12″ MacBook, and it won me over. I couldn’t find a Pixel anywhere in Portland, so it never had a chance to make its case in person.

In its own way, ChromeOS is Google making a comment about computing the way Apple does with iOS: Both would like you to consider the hardware comfortable and pleasant to use, but neither want you to really care about the hardware. They want you to care about the experience the hardware delivers.

“But Mike, Apple is a hardware company!”

Yeah, yeah … right. They sell hardware. I get that. But they don’t want you to care about what’s inside the case in terms of RAM or clock speed or whatever any more than it takes to help their customers spend as much as they’re willing to optimize the experience.

Google’s approach is maybe more utilitarian:

They want you to realize you could take your Chromebook down to the river, toss it in, order up another one from Amazon Prime Now, have it delivered to your door two hours later, and pick up where you left off. Where the most sensible accessories for MacBooks are padded cases and maybe a grippy protective shell, I can imagine a future where the most common accessory for a Chromebook is a little holder for disinfectant wipes so that people can swab down the one they found left out on a picnic table at a public park or next to a puddle of vomit in an Old Town alley.

“How’s that Chromebook you found?”

“Oh, it’s cool. The last guy replaced the escape key with a human tooth and there was some hair and clotted blood in the USB port, but when’s the last time I needed a thumb drive, right?”

“Ha ha right … Hold it … a tooth for an escape key? Oh shit! That’s the one I lost after Murray’s bachelor party last year! Man. Wonder where the hell it’s been?”

“Oh yeah? No telling. Want it back? I found another one out on the curb this morning.”

“No, it’s cool … that one was just my clubbing one.”

Okay, that’s overstating the case. Dell just released a 13″ Chromebook that could properly be called a “business machine.” Nobody’s IT department will be happy if one ends up in the river, or left on a playground. But the i3 model is pretty inexpensive and very capable. The i5 model is pricier, but I bet it’s way less frustrating than a comparably priced Windows machine in terms of perceived speed. Maybe more importantly to an IT department, nothing lives on those things. So if one does end up in the river or gets left behind on the bus, it’s a little less costly to replace the hardware and the data doesn’t have to be “put back.” Just pull one off the shelf and slide it across the counter.

Linux on the Dell Chromebook 11

I was feeling a little poorly over not being able to try out the (somewhat scary) “flash a more flexible BIOS, turn it into a ‘real’ Linux machine” approach. I mean, it wasn’t something I wanted someone trying on my advice. I felt poorly about it because my curiosity was thwarted. I set about to fix that this morning and it was pretty simple!

  1. Pick the distro you’ll want to stick on the machine. I went with Ubuntu and used the UNetbootIn app to burn the install CD to an SD card.
  2. Crack open the case and void your warranty to remove a write-protect screw that’s designed to keep you from overwriting the BIOS. See the picture above for where to find it. Put it somewhere safe, I guess, against the day you want to restore the Chromebook to its pristine state. I kind of love the physical hardware aspect of the operation. There’s something deeply psychologically unsettling about knowing the machine you’re holding is literally missing a screw that you took out of it. I like to think they settled on the write protect screw after testing “make the user crush an ampule of cat urine over the keyboard” and deciding that sourcing cat urine would be cost prohibitive.
  3. Put the machine in developer mode. There’s a little fussing and it takes some time (they just don’t want you to do it), but it’s a simple process. At this point, if you reboot the machine it will give you this warning screen and provide you with an easy way to get back to “normal.” The screen is a clean white, and there are no sounds of screaming at bootup because that would be bad UX, and because it reduces the chances of you loaning the machine to someone who literally just taps the spacebar at boot to wipe out all your customizations.
  4. This step is dangerous. If opening the case and removing a screw didn’t deter you, this is probably the best point at which to pause and ask whether turning your Chromebook into a dedicated Linux machine really matters. Download and run a shell script that flashes the ROM with SeaBIOS. That will allow you to boot from a USB stick or SD card to run a Linux installer. With the Dell Chromebook 11, this is an all-or-nothing situation. Some Chromebooks let you dual-boot between ChromeOS and something else; this one does not. If you screw it up, you’ll risk bricking the machine.
  5. Reboot from the SD card or USB stick you burned in step 1 and run the installer.

Once you do all that, you have the basics: The machine boots into Linux, can talk to the network, and generally “works.” There’s no sound, the trackpad is sort of weird, and the special function keys don’t work. You can take steps to fix all that. Here’s a starting point, none of which have I attempted: I made the machine boot into Linux because I wanted to see what would happen.

What happened was pretty anticlimactic:

rbenv, Emacs, zsh and git are all just an apt-get install away. GNOME is GNOME. Firefox was just sitting there, and I used it to Google “john lewis restore chromebook stock ROM.” Then I downloaded the script I used to flash a new BIOS in the first place, told it to please restore me to the stock ROM, and let the Chromebook boot into its recovery media (which I made last week before I started screwing around with the machine). I’m pretty sure I’m not even going to bother putting it into developer mode again, and I need to put that screw back in place once it’s done reinstalling ChromeOS … It’s sitting there on my desk bothering the hell out of me.

Linux Anywhere But the Dell Chromebook 11

Why not even put it in developer mode?

Because I don’t have to. I’ve already got two Linux machines (one I own, one I rent via shared hosting). It turns out Chrome has pretty decent ssh client you can use, and I did for the week I was playing around with ChromeOS and doing that writeup. Stick the ssh client tab in full-screen mode, and it looks about like the ssh client in full-screen mode looks under GNOME, Unity, OS X, or my iPad.

The thing you get from developer mode/Crouton is offline availability of that more robust environment. If I traveled a lot, that would matter. As it is, I’m almost never disconnected. If there’s not Wi-Fi, my phone is a serviceable hotspot. The “little CLI workstation with Emacs and Ruby” is never far away. It just happens to be running somewhere else. That’s kind of the point of the thing.

You can’t say what you are, but you should try anyhow.

I say ‘I consider myself a feminist,’ because I really do. But I always feel like I’m taking a big risk when I say ‘I AM a feminist,’ because there is always, always some other feminist out there who will show you that you’re wrong. Usually they’ll also show you that you’re awful for it.
— Someone somewhere I visit regularly

Another feminist here. That’s an understandable sentiment.

Personally, I hate calling myself anything at all, ever. I spent four years trying to reconcile what I thought I was, what I wanted to say to people I was, what I wanted people to think I was underneath, and what I wanted to be with what I was being every single day by just waking up where I was waking up and doing what I was doing.

I spent even more years after that trying to work through whether I’d ever known or could ever know what I was: Maybe I’d stopped listening to my better angels. Maybe the better angels had never been real. Gandhi had suggested that nonviolent behavior could be motivated (and tainted) by cowardice, so I wondered to myself if what I’d thought had been a nonviolent worldview hadn’t actually been a sort of cowardice, and that by enlisting maybe I’d just embraced what I’d always been.

Some understandings about myself and the world around me crystallized, some things just got more complicated:

Could I jump out of an airplane at night? Yes. And for the last year I was jumping out of airplanes, it’s fair to say I was frightened every time. By the time I got to that point, I’d healed up a lot. I wasn’t who I’d been when I walked into the recruiter’s office: If the controlled environment of the army had been a splint or a cast, it ended up setting my bones into shapes they hadn’t been before I enlisted. So I gained some understanding of what it is to be deeply afraid and yet still do the thing you set out to do. For a period, living that pattern allowed me to say to myself that I wasn’t a coward, that I had a core I could depend on. So I started looking beyond where I was, and having thoughts about what could be next, and wanting it. I didn’t want to give up and disappear into the army.

Then I was out, and rather than going back to be near the people who had cared about me and supported me while I was in, I chose somewhere else. I couldn’t just go back to where I had been, among people who might have been tempted to say, “well, that’s all over now and you’re back.”

I was loved and cared for, but not a lot of people knew me. They just had the biography, and that question of cowardice was still very real, and was suddenly unresolved again because I figured out that physical courage isn’t moral courage. So, I wanted the new people in my life to know something more about me than where I’d been, but I was still struggling with what it was I’d want them to know, and if it was possible for there to be anything more to know. After all, there was what I thought I was, what I wanted to say to people I was, what I wanted people to think I was underneath, and what I wanted to be, but there was what I had been every single day for four years by just waking up where I was waking up and doing what I was doing:

I’d been the guy who got sent to the chaplain because he wouldn’t sing the baby-killing cadences, and then invited to declare himself a conscientious objector. Didn’t do it, though, because I wasn’t. I just didn’t like baby-killing cadences.

I’d been the guy whose boss told him he should seriously consider taking a subordinate into the woods to beat him up, and briefly wondered if it would need to come to that, then learned how to make anger and its energy palpable; maybe to help avoid taking that step and maybe to make it easier if I had to.

I’d been the guy who told a barracks bully that I’d take an eye or an ear, and needed to believe it.

I’d been everything that environment demanded of me, and I chose to stay in it.

I nearly started typing, “but in the end,” because that would allow this to be narrativized and resolved. But there’s no end because I’m still sitting here typing. There’s an ever-unfolding now that I needed to learn about.

There were all the moments where I looked back on some of the things I said and did and hated them. When I’d tell stories about things I’d seen or done and I’d realize people were repelled by the mere fact that I’d been there to see them. There was the year where I needed to get help because I’d see a picture of a maimed child in an Iraqi marketplace bombing, or read about a murder-suicide on an army post from some solider who’d come back from the wars changed, and I’d think about how I’d wanted to be some part of that, and that’d be it for the day, stopped by anger and grief. I’m so glad I worked at home: I don’t know what I would have done with people around when those moments came. Maybe I would have just swallowed it whole instead of composing some polite fiction of a status message and going to sit in my room.

Then there was just more life, and a slowly growing recognition that I couldn’t ever un-be those things. When he was little, Ben thought I’d once been a knight. It was heartbreaking to explain that I hadn’t been. But it was strengthening to realize that the more truthful I could make myself be with him, the better a parent I could be to him.

I figured out that I had to start being the person I wanted to be in that ever-unfolding now. I had to accept that some people would see the biography and think things they’d be justified to think, and that I had to set that aside: There’s no erasing it, and to erase it would be to erase me. Instead, I had to learn how to be open to the things that I can hear and feel are right, and accept that they might be incongruous with what I’ve been.

Because of all that, because I once set aside everything I said I was and became something else, and because I then spent years trying to make all of that make sense, I’ve got a deep aversion to saying I’m anything at all. To the extent it’s any of my business how people talk about themselves or what they are — and it almost never is — I wish there’d be less “speaking as a …” and more “because I live my life thus.”

At the same time, self-identification helps people, right? It helps us hold each other — and ourselves — accountable.

I read bell hooks’ Feminism is for Everybody where she writes “the soul of our politics is the commitment to ending domination,” and I thought to myself “yes, that’s right, I want to live that and teach my son that.” I put down the book and thought “I agree with her, and other people who call themselves feminists,” and then I felt okay saying “I’m a feminist.”

Despite my aversion to saying “I’m this” or “I’m that,” I think “I’m a feminist” is a thing worth saying.

Because I’m a man, steeped in this culture and taught habits of thought that are anti-feminist, I’ll sometimes do things that aren’t feminist things to do. I’ve been lucky to have people in my life who have been gentle and patient with me when I’ve done this. Some day I’ll meet someone who won’t be as kind, or who will want to prove that I’m not a feminist at all. Depending on who that comes from, that could be upsetting or embarrassing.

The alternative, my heart tells me, is to be less supportive than I could be; to be an “ally” who can still maybe slip back and forth, maybe never having to own being wrong or hypocritical ever again because I remember how hard it was to put a sense of self together again after being something besides what I wanted to be.

All we can do is be what we are in the ever-unfolding now. We can open ourselves to hearing what’s right, and we can try to choose what’s right, or at least choose what’s less wrong. We can accept that we’ll sometimes fail at that. We can allow ourselves to be held accountable. We can try again.

© Michael Hall, licensed under a Creative Commons Attribution-ShareAlike 3.0 United States license.