Month: December 2013

Puzzling

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.

Hello!

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.

© 2017 Emily St*

Theme by Anders NorenUp ↑