Work Retrospectives

Screenshot of my first weekly work retrospective
First retrospective of many

I decided I didn’t want to get caught next year trying to write my review without any idea of what I had done the year before, so I’ve decided to start tracking what I get done from week to week. I’m going to try to write a weekly retro every week of 2014.

I have time blocked off at the same time every Friday morning to spend about half an hour referencing salient tasks, time spent, people I’ve worked with, and projects I had involvement with so that I can scan through in 2015 and catch a bird’s eye view of the landscape of my year.

Incidentally, for the moment, I’ve decided to try using Day One for tracking all this, if only because it has great support for searching and viewing past entries over dates, and it syncs between all my devices. I could probably throw Markdown on a server or use a private WordPress, but scanning is so much faster this way.

In Case of Review, Break Glass Ceiling

For the second time in my professional life (first time here), I had to turn in a self-review to my manager. Our self-reviews are part of an overall review process, asking for scores and supporting comments in a number of areas of our job (quality, leadership, problem solving, planning, and so on).

I’m awful at anything falling under the purview of “professional life.” I struggled with it again, like last year, and it stayed undone till the last moment (and then some—I had hoped to finish it last week). What’s worse, I felt like last year I used up all my best review lines talking myself up, so I had nothing but utter dreck to spew this year. I couldn’t even remember anything that had happened in the past year. All that came to mind were the frustrations I grappled with and complaints I brought up.

Time got short and I had almost nothing, so I passed in the review with little content and a lot of fields left blank. My manager bounced it back almost right away, basically saying I could do better. Well!

I had struggled with it off and on for weeks, and I had no idea what he wanted or what the expectations were. Finally began to vent to a coworker. She mentioned she had struggled with hers too. I asked her what she did.

She’d done the same thing, asking others what they had done, and had even gotten to peek at a few other reviews from (male) coworkers. I have always had trouble talking myself up, but it seems like they hadn’t struggled with this at all. They came across in their reviews as highly accomplished and even boastful, to the point where she felt less sure of herself, to say nothing of my reaction. I had barely written anything, and what little I did write was either unsubstantial or actually critical. The self-review also called for numerical scores in various areas, and mine were really conservative.

I asked her, “Do they actually lie?” about their reviews, and she said, “No, but they dress them up in tuxedos.”

I’m really thankful to my coworker, though. She helped a lot to get me started finding some real content and suggestions.

First, she suggested searching for past code reviews I’d requested. While it hadn’t been very useful for me to be told to “search my e-mail” for the last year, the code review e-mails helped to link to related issues I had worked on, short summaries of what I had accomplished, and a general landscape of the projects I’d worked on. This was a pretty great direction to start with. It helped me remember various projects I’d been on.

I got some ideas for other kinds of e-mails to search for, like postmortem threads where we had dealt with urgent service problems.

She offered to let me see hers, but I passed. In the end, though, I let her look over mine, and she helped clarify what some of the categories (like “job knowledge”) actually meant, so I was able to fill in parts I had misinterpreted. She also pretty much made me raise every one of my scores after some back and forth, reminding me of a lot of things I had forgotten. I ended up going with her suggestions since she had more context than I did from looking at other reviews.

By the end, I was much more amenable to her suggestions because I had so much more supporting detail. It definitely didn’t hurt, either, that I was inspired by an article in Model View Culture (written by my friend Kronda!) to be a little kinder to myself.

Incidentally, another friend on IRC had suggested keeping a high-level journal throughout the year, and that would probably be really useful for me, considering this. I probably won’t, though, and next year I’ll panic about the whole thing all over again.

Why I Don’t “Code”

I don’t really like the terms code or coding used in place of program or programming respectively. I’ve felt this way for a while, and I’ve tried to prefer saying “programming” over “coding” wherever possible.

As a shortened form of source code, “code” and “coding” were probably inevitable. To me, though, I can’t help but hear them as synonyms for cipher. They feel like a subtle call-out to programming-as-esotericism, into which a small elite has been initiated, using its own arcane symbols and language.

It doesn’t help that phrases like “bro down and crush some code” have come into (and hopefully back out of) vogue.


Screen Shot 2013-12-31 at 13.39.54I’ve been playing a lot of the older Legend of Zelda games lately, since OpenEmu arrived on the scene and changed things. Link to the Past was my favorite.

The entire in-game world was just a single massive interconnected puzzle that took months of playtime to unravel as a kid. Every single thing you saw, got, heard, or did had some significance in understanding and unraveling the next piece in the puzzle. For a kid with wicked, above-average recall, it played to my strengths. That was probably the reason it appealed to me so much, and at the same time, fucked me up so much.

I went into life later already in the habit of working out and memorizing every single thing that passed in front of me as if it were some puzzle that held a part of the key of figuring out the entire world. That definitely didn’t serve me well.

My interest in the Legend of Zelda series waned around the time I hit puberty (and video games began figuring out 3D).

Toward Test-Driven Writing

In programming, we use a methodology called test-driven development. For every piece of a program we write (often called a module), we also write an accompanying suite of test cases. Ideally, you won’t find a single piece of source code that goes untested. It sounds slower, but it actually improves quality so much that it has become (mostly) uncontroversially accepted as a best practice.

Testing a piece (a unit) of code is pretty simple. Each little test asserts an assumed behavior by following a similar pattern. It sets up the environment in which that behavior should happen, runs the relevant unit of the program, and asserts the expected result. You’ll find dozens, hundreds, or thousands of these little tests for a given project, and importantly, no one may change how the project works without making a test case for their change and proving it works, independent of the other parts.

Better yet, to an extent, tests can replace explanatory comments. By encapsulating the expectations for your program, I can better describe a program’s design by illustration. Unit tests therefore serve as documentation, sometimes even the only way to understand a program.

I’m beginning to see how it might be useful to apply the test-driven model to writing. I want my writing to make a strong, believable case, against which readers can make unquestionable assertions. I’ve heard the advice to “show, don’t tell,” and I always thought it meant something like including supporting detail. Maybe that’s not quite right. The advice is not to tell at all, instead of simply backing it up. It tells me both what to write and what not to write. Just like with a unit test, I don’t need to stop and explain.

For example, suppose I want to describe a character who loves another. I might say, “Alice loves Beth.” But that’s clumsy. It sticks out of the story, rather than reading as part of it; I’ve stopped telling the story to impart this premise. Worse yet, “love” is a slippery word—it means something different for each of us. What kind of love is this? Family love? Romantic love?

What if my idea of love falls outside the reader’s experience? That is to say, what do I have to say about love itself? “Alice loves Beth” squanders the opportunity and remains silent on the subject.

In fact, let’s not say “love” in the first place. That word carries a lot of baggage. Maybe I’m not even describing something the reader would ever qualify as love. I might find I’m just bluffing, and the reader only has to call my bluff for the assertion of love to fail.

Suppose instead I write a passage like this.

Taking it down from its hanger at the back of the closet, Alice held Beth’s shirt close and inhaled slowly, afraid that she’d exhaust the source of Beth’s lingering scent. Like a flashbulb, it revealed fleeting memories, which rushed into Alice’s mind’s eye barely long enough to register before slipping away again.

I didn’t say, “Alice loved Beth,” nor did I say, “Alice missed Beth,” but who could question that those statements are true? And there’s more. We know Beth is gone, in some form that allowed her to leave behind a shirt but not much else. A faded scent demarcates a rough idea of the time passed. Something irrevocable happened. A bad breakup? A death? Possibly Alice is moving, or maybe packing up Beth’s belongings. I didn’t even indicate whose closet Alice was in. We do definitely get a sense of some romantic love that could have involved cohabitation, so that distinction may be immaterial.

My point is, it’s not just about how you feel after you read the passage above. It’s more about stating what’s immediate and undeniable, making a case, while leaving out flimsy or even misleading commentary. Within this context, every action in the story fits and drives the narrative forward. The idea of test-driven writing—even though there are no actual tests involved, beyond the reader—helps me better understand what to write, and what not to write.


Another year, another new blog. I seem to create a new one of these every holiday season. I get some time off and inevitably figure out what dissatisfies me about the previous personal site I had up—despite having gone through the same process last year, and the year before, and so on; despite leaving the site to languish for months on end; despite the urge to burn it down and start all over.

Let’s do it again. I hate WordPress, but it’s so awfully convenient. I’m probably the only person ever to migrate away from Pelican back to WordPress, so I’m going to have to do so largely by hand. I think I’ll go back and pick out the entries that make sense. That is, the ones which have little to do with the process of setting up and using Pelican, I suppose.

So this won’t be the first entry in the system, but it’ll be the first one made for this particular site. At least I won’t be starting over from scratch. Maybe I’ll leave this one up for a little while.

On Distinguishing Microaggressions

While for me the word “microaggression” made sense immediately, I’ve met people for whom the meaning doesn’t land right away.

The distinguishing feature of a microaggression is that it inflicts damage mainly by attrition. That renders the damage invisible, when taking any one isolated incident. It’s a siege tactic; like any offense, though, it ultimately works towards the same defeat, oppression, and hegemony as an outright attack. It’s only when taken in the aggregate that the damage reveals itself.

Most importantly, an invisible attack is hard to rebuff. You certainly feel it, but no one else knows what’s going on, maybe not even the attacker. By consequence, your defenses are lowered because any response looks like escalation, possibly alienating any sympathy and provoking further attack. This feeds into a kind of gaslighting where you’re not sure anything even happened, even as the inflicted damage remains.

That’s why I feel pretty glad the idea of microaggressions is being spread, to mitigate that cycle.

(Not Quite) Everything You Ever Wanted to Know about Leaving Google (And Were Afraid to Ask)

I thought I’d write up a bit about how I’ve gone about leaving Google and why I’ve done so. This is going to get a bit long, so bear with me.

This was a pretty personal decision on my part. It’s not something I generally recommend at this point. Once you try to fight the Google hegemony, you really start to realize how pervasive and powerful it is. Google positions itself as a kind of default for the web services that make up our daily lives—mail, documents, search—and even as organizational foci, like with groups, document sharing, messaging, and now Plus.

I think Plus was the thing that really started to drive a wedge between Google and me. As Google began to push Plus aggressively and made questionable policies around it (like the nym wars), I began to see Google as a corporate entity whose goals were fundamentally at odds with my interests as a person. The bottom line is that I didn’t want to be a product anymore.

I also worried about the future. Now that Google has shown the potential to tear down well beloved and well used services (like Reader), what else would they do? Talk is becoming a feature of Plus. Would mail eventually become so? That’s not what I want.

I want a home on the Internet. Or maybe a homestead. A place on which to hang my identity and remain static as long as possible. Changing from service to server a few times a decade is very awkward.

To this end, I registered a domain for my personal use (the same one which hosts this very web log) and began to wonder how best to set up my own services.

Google provides a lot of services. I wanted to replace the majority of them, where it made sense. For this post, I’m going to talk primarily about the ones I use for personal information management and communication. For me, this includes Mail, Calendar, Talk, Groups, and Voice.

Initially, I wanted to replace all these services with self-hosted open source services on a virtual server. That’s still certainly possible, but as time passed, I realize some services just weren’t worth my time or money to set up and maintain indefinitely. I realized, in some cases, that the software isn’t quite there, and in other cases, I couldn’t accomplish my goals that way. All that matters is that I control the domain and the data, really. Replacing Google has meant questioning my motivations and goals along and along and making decisions accordingly.

As an example, the first thing (and biggest thing) that I wanted to replace was mail. Gmail has innovated remarkably in the space of mail user agents, leading to amazing clients, and I’ve used Gmail exclusively for the better part of a decade, so the bar was a bit high in that regard. I also figured that server-side mail transfer agents had equally advanced in the time since I had last set up a mail server.

I was wrong. Mail servers have changed very little. What seems to have changed the most, with regards to MTAs, was all the other rigamarole to avoid being marked as spam. Between making sure my DNS setup was just right, getting DKIM signing working, making sure I had working SSL certificates, and so on, I felt like I had gotten in over my head. It certainly would have been workable, but I didn’t want to have to maintain that mess (and spend days encountering subtleties in my setup that made it insecure or flub a command and risk dropping mail on the floor).

There was also the matter of an SMTP server. I would need to send my mail somewhere. Probably using my ISP’s supplied SMTP servers? The days of sending mail around directly from server to destination in a trusted way are over, from what I can tell. This means, no matter what, I couldn’t be on my own with mail or completely avoid US-based MTAs from seeing my mail (even if the transmission itself were secure) ((I may have misunderstood all this; if so, disregard.)).

Some services just are best left to the pros.

I asked around for recommendations, and it sounds like, these days, most people are using Pobox or Fastmail. The biggest disadvantage I can see with either of those are they host themselves in the US. I don’t know what sort of PRISM arrangements the NSA has made with these providers, but after checking out Fastmail, I decided that I liked them enough that I didn’t care. Avoiding surveillence wasn’t one of my primary goals (though nice if I could accomplish it), so I ended up going with Fastmail.

For now, I’ve pointed all mail to my domain with a wildcard to come directly to my Fastmail inbox. It’s worked really well so far! I haven’t encountered spam yet, so I can’t speak to how well Fastmail deals with that, but every other feature I could want seems to work swimmingly (server-side filtering, nice UI, secure, and so on).

I have changed my mail address for most lists and services, giving each its own specific address. The transition is really still ongoing, as I wait around and see what mails end up going to my Google account and addressing the source.

I think the most awkward part was moving over Google Groups subscriptions. I’m not going to get into that subject here in detail, but suffice it to say, it’s almost completely undocumented and awkward to achieve for private lists, but it’s absolutely possible.

If mail was hard, setting up an IM server was a dream. I ended up using Prosody on my EC2 instance for XMPP ((Fastmail advertises that it has IM, but in my experience, it didn’t work, and others on the internet have complained about it.)). The only qualm is, again, interacting with existing Google users. I’m disinclined to add Google contacts, knowing I may lose communication with them at any moment—and not even know it. Maybe Google will change course someday, or maybe someone will figure out interoperability somehow despite Google. I doubt most people I know will end up moving en masse to another, more interoperable service.

At the polar opposite end of ease, I totally failed to get a working setup for a calendar server. Fastmail does not offer calendaring, contacts, tasks, or notes. I thought I could reasonably set all that up through some sort of DAV server, and I wasted probably weeks of my life (off and on) trying to find one that I could get working on my EC2 instance.

They were almost universally impossible to get working in a way that felt obvious, secure, or straightforward, and it was maddening. Every solution I found was either overengineered groupware or someone’s beta-stage private project.

Eventually I learned about Fruux on Twitter. I initially felt a pang about giving up control over this service, as well, but they won me over handily once I actually tried them. Compared to all the hours of effort I wasted trying to set up my own service, Fruux was so easy, it was like falling in love.

Okay, great, I’m no longer using Google. Now what do I do about my account there and all that data?

I want to keep the data forever and control it. I want to ensure my privacy (inasmuch as I realize the horse has already left the barn) for that backed up data.

I’ve used a combination of exports (for Calendar and Contacts), Google Takeout (for miscellaneous services, such as Voice), and a nifty app called gmvault for Talk and Gmail. All this data goes together in a directory which I’ve archived up, compressed, and GPG encrypted. As for long-term storage of this archive, I’ll probably use an archival quality CD and a flash drive.

As it all weighs over half a GB compressed, I doubt I’ll be able to print it all as a hard copy (and I’d worry about that if I did so).

Now, with the data backed up, what about the account? I’ve left my account active for the time being. It’s too abrupt, for now, to cut myself off from all Google services right now. Maybe someday in the future.

Zen Not Zen

On my day off, I was browsing the Internet and came across yet another nonsensical use of the word “Zen” to adorn a programming project. This isn’t the first time I’ve seen this in the wild. A quick search of GitHub shows an undeniable pattern.1 Even GitHub itself is complicit.

A quick glance at some of the (sometimes grating) descriptions and documentation for these projects reveals the use of “Zen” to connote simplicity, ease, and minimalism. Especially minimalism. I think the idea is to evoke harmony—with nature, with the user, with the computer, or with whatever—and peace, inasmuch as that can come from a computer.

(Searching the Internet some more, I came across a wonderful term, a “dharma-burger”, to describe this combination of Buddhism and pop culture via marketing.)

I am not a Zen teacher, practitioner, or student. However, I have to try to imagine what sort of dialogue I might engage in, were I on a team of engineers who were all white and raised in the West.

Listen, everyone, I don’t think naming this product “Zen” is a good idea. I know that we’re all white here, and when we hear the word “Zen,” we think of a certain minimalistic, natural aesthetic. We definitely want that sort of aesthetic, too. We want our product to feel good and be second-nature to learn.

I don’t think we can use “Zen” as a shorthand to refer to that aesthetic or philosophy, though, because there are a lot of people who have very different associations with the word. The bottom line is that we need to make a decision, now, before we ship, whether we want those people to be among our users or even among our team in the future.

In short, to my mind, it’s needless and offputting baggage. In other words, “Zen arts without Zen study is just cultural junk.”