Finally got through the extended edition of Lord of the Rings. Made a GIF to celebrate. It pretty well encapsulates work this last few days.
It’s been a passing fad lately for some acquaintances of mine to write about their tech origin story—how they came to tech, perhaps as a child or young adult, and found a place for it in their lives and identities. I probably haven’t shared much about mine. The story gets a bit personal, touching on class background, among other things. Its trajectory, though, took me far away from where I started.
I started my story growing up in a rural area of southern Georgia. I didn’t have any access to a computer from a young age. My family had a TRS-80 that I struggled to hook up to the TV, and I managed to tinker with it a bit, but it was never much more than a toy I used for a few weeks and forgot. I don’t count it. It didn’t come with games or programs, nor the ability to store these. It didn’t connect to any other devices or networks. All it did was run BASIC instructions. I didn’t get far with it, and I didn’t remember much about the whole thing until later in my life.
I don’t recall childhood as a time of achievement, either. From about the second and third grade, I began failing classes and getting punishments such as writing assignments, detentions, and eventually in- and out-of-school suspensions. The reasons why are complicated and personal. We’ll skip ahead a bit. Suffice it to say, I spent most of this time ignoring school and just reading and writing things outside of class. I got a typewriter instead of a computer.
I failed too many classes to graduate high school on time, nor did I make it to graduation, and I certainly didn’t have the kind of GPA or scholarships that would have put me on track for college. This put college almost out of reach. I didn’t know what I wanted to do, and mental illness intervened and prevented me from making much of myself for a few years. During this time, I set foot in a couple of college or college-like settings, but only for a few months, and I invariably failed every class I took.
Let’s turn to the tech part of the story. I didn’t get a computer of my own until the end of high school, and I was incredibly lucky at that (interesting story full of weird happenstance, but I’ll save it for another time). I didn’t really know what the Internet was until high school, and programming was unknown to me until around the time I finally got a computer of my own.
I did learn programming, though, around that time. I did so quickly at that. It soon became really important to me to be able to control a computer on every level. Awareness of open source followed closely upon that. Within a couple of years I started trying to throw up websites for people. To round out my abilities, I ran my own server out of my house and set up everything from scratch on it, learning how to run e-mail, web, IRC, and everything else. I read everything I could to the point of exhaustion.
This all happened while I worked in food service, and while I had a vague awareness that these sorts of abilities were useful, my profound failures in school had daunted me, and I had already long ago decided I needed to finish college before I considered some sort of “real” job. People began telling me quickly I should try to apply for this or that, or asking why I wasn’t in a computer-related job, and all I could say is, I have no degree! I have no qualifications, experience, education, training, certifications, or references! This grew into a litany—I could knock down others’ vicarious ambitions for me more quickly than they could even articulate them.
I dreamed someday of going to college and getting on track to become well lettered, researching interesting problems, meeting people brilliant beyond reckoning, and having the means to drag myself out of the dreary life I led driving around in an old station wagon catering for people. Yet, I felt like I had squandered my one chance, and that dream was out of reach. I didn’t know what to do.
I can describe this time as basically wandering around. For several years, I moved through a handful of towns in Georgia. A lot of very important things happened to me, but those are other stories. Eventually I wandered by chance up to the Pacific Northwest, living across the river from Portland. I did transcription work for a half a cent a word to bring in a little money, but I wasn’t getting by very well.
I began to meet people, and most of the people I met through IRC in the area were into tech in some fashion or another. One day, someone told me to apply at their company for a programmer position. I took a look at the requirements and instantly said, no! It required a four-year degree (or equivalent, whatever that means) and experiences and technologies I knew nothing about. At this point, I had never touched SQL, nor had I ever used Perl.
He told me to apply anyway. Here’s the important part: Had not someone from the company specifically told me to disregard the formal requirements, I would never have acted. As it is, I did, and that changed everything. Despite my lack of experience, they saw potential and gave me a chance. From that point, I picked up the job really well, getting two promotions over the next two years and in the meantime gaining all the experience I had previously lacked.
I’m glad I applied, but even more, I regret not applying to tech jobs before that point. I think back at so much time in my life I spent holding back, being my own worst enemy and dismissing my opportunities out of hand before they could even happen. I have spent more than a few moments wondering why I didn’t apply before. Even if I hadn’t hit success right away and met with rejections, what was I holding myself back from?
“One of my friends said I should ‘shake it off.’ I told her I shook off the last 999 times.” —Kronda
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.
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.
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.
Just a quick aside to show off my new shortlinks format on WordPress. You can find this post, for example, at
I’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).
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.