TDTW (Test-Driven Tech Writing)
By: Kaelin Alexander
Tags: Tech Writing, Epistemology, Learning And Development, Coding, Career Change

An unlit lightbulb.

This week I’d like to take a step back and offer a bit of a mission statement for how this blog will function moving forward.

Based on a not-so-comprehensive (but surely algorithmic) review of articles referred to me by Medium dot com over the past few months, it seems like a lot of tech writing on this platform tends to fall into a few generalizable categories:

- Walkthroughs for specific tasks

- “You’re doing [X] wrong, did you know?”

- Listicles (usually of libraries or methods to know)

- “Get to green lights with this one weird trick”

To be clear, all these kinds of tech writing are valuable, helpful, and necessary. The algorithm is pushing these genres of writing out because they serve a purpose and have an audience (and that audience is often me, or people like me: recent Coding Bootcamp graduates who need all the help we can get).

Thing is, as a Babycoder, I don’t know that I could or should convincingly produce writing for Medium dot com that falls into any of those genres — not because I couldn’t do the research necessary to make a list of urgently helpful Node packages, but because I’m simply not the person to write that article; I’ve been using Node for a week, and while I’m excited to be learning it, I’m sure as hell not ready to make any recommendations about it. I cannot and do not need to pretend that I am a Knowing Subject™ when it comes to coding.

More importantly, though, as I transition into tech, I’m not actually sure a Knowing Subject™ is something I want to be, much less something I want to perform. Part of my aversion to being a Knowing Subject™ stems from my values. For me, intellectual humility is a really important emotion to cultivate: it keeps us honest, keeps us open-minded, and keeps us relational.

Beyond that, though, I have an incredible suspicion that Knowing Subjects™ are often (not always) subjects for whom knowledge is indelibly tied to authority. We’ve all met people who use what they know as a way to bully, cajole, and overpower others, to various degrees of success. In many contexts, such behaviors are normalized as essentially “earned by qualification.” Knowing, especially knowing without a continued commitment to learning, can lead to pervasive forms of structural and interpersonal violence. And no thanks.

Back when I was an academic, I spent a lot of my time worrying about my status as a Knowing Subject™. On the academic job market, convincingly presenting as a Knowing Subject™ was one of the major keys to landing a tenure-track job. I couldn’t, and I didn’t, and I don’t regret it: I am not interested in being, or having, authority.

Unsurprisingly, much of my pedagogy involved actively displacing my students’ seemingly default belief that my knowledge or perspective was somehow de facto truer, more valid, or more valuable than their own, or that of anyone else, simply because I held a credential. Surely, the extent of default for that belief had a lot to do with the fact of my presenting as a white, cis, queer man in a world where white, cis men continue to be given the completely unearned benefit of the doubt when they make claims as Knowing Subjects™— and are often interpellated as Knowing Subjects™ even when such claims aren’t made.

Holding a PhD did not mean that I inherently knew more or better about a text or topic than my students did. I was not somehow transformed by my years as a bookworm into an essentially different kind of being.

What was the actual, substantive difference between myself, as a literature professor, and my pupils, as literature students? I had simply had a lot more time and motivation to read, to notice patterns, to internalize and apply accepted methodologies, to formulate analysis, and to put my arguments into writing. In other words, holding a PhD meant I’d had time to practice. But I still had (and have) blind spots, gaps, and a perspective that is intersectionally situated. And more importantly, I’m still learning.

To be clear, I’m well aware that Americans have a particularly fraught relationship to knowledge. Over the last few decades, it’s become increasingly clear that, for some people, an uninformed, but strong opinion is magically equivalent to years of researched, contextualized expertise. This false equivalence is a problem, full-stop, and not just because it is literally costing lives in 2020. Ignorance, unfortunately, yields authority too.

To be very clear, then, I am precisely not arguing that my students were, or could have been, “the real teachers” in the room any more than I am arguing that the Karens and Chads of the world should be arbiters of public health. Practice, expertise, and a commitment to continued and collective learning matter, vitally. The Karens and Chads of the world haven’t just stopped learning, they’ve also stopped listening. And no thanks.

At the same time, I’d also like to enter tech fully aware that I value learning far more than I value knowing. And, with that priority in mind, I’d like to reposition this blog as an opportunity for exploring my process of learning tech, rather than any state of knowing tech.

In other words, I’d like to fully embrace TDD as both ethos and method for what this blog could become. On the ground, this will mean exploring ideas as they’re unfolding in the moment, forwarding hypotheses without having finished all the tutorials, and simply trying things out with avid, open curiosity. Part of this emphasis on intellectual openness arises from purely pragmatic future-proofing, too: in coding, there will always be more to learn.

I’ll be returning to ideas that were wrong and gleaning value from that wrongness, rather than in spite of it. I’ll be making false starts down cognitive dead-ends. I’ll be learning, then unlearning, bad habits. I’ll be sharing my failures much more often than I’ll be showcasing my successes because that’s why TDD is valuable in the first place.

So, if you’re looking for Expert Tips, either in truth or in drag, then this is not the place to be. Instead, the process-driven writing here will hopefully serve as as a very different sort of resource that is just as engaging and instrumental—not because it’s perfect, but because I do my best learning and write my best code not when I’ve reached MVP, but while I’m still in testing. Maybe you do, too.

(Photo by Mohamed Ahmed on Unsplash)