When I started college at the University of Central Florida in fall 2004, I enrolled as a computer science major. I soon switched to the English technical writing track, for a number of reasons, including:
- disappointing quality of instruction from the computer science department,
- a (faulty) prediction that a large percentage of software development jobs would go overseas, and
- an (in retrospect, also faulty) assumption that I wouldn’t be particularly good at making software.
I don’t regret the decision, even though I do regret some of my dumber reasons for doing it. I love what I do now. Not only is writing a pleasure to do, but I find that a lot of the time I’m not bad at it. On occasion, I’m actually good at this sort of thing.
However, I still have one lingering apprehension about choosing technical writing over a perhaps even nerdier profession and that is this nagging notion that I don’t actually make anything of intrinsic value. In other words, the things I make, like tutorials, references, and screencasts, don’t have any value in isolation. It’s easy for me to consider that some piece of software or a particular system that I write about is useful in and of itself, but things I write relating to them are, in a sense, ancillary.
I don’t enjoy this line of reasoning. Foremost because it has the quality of an excuse to simply not try very hard. If it’s not important, why bother? But it also distresses me because it diminishes the actual dollars and cents value of what I do. And not in the sense that such a line of reasoning implies I should be paid less (note to bosses: it doesn’t) but in the sense that if what I do lacks value, then getting paid for it is somewhat dishonest or fraudulent.
Under a strictly practical examination, the idea that what I do lacks value doesn’t hold up to scrutiny. Simply put, I solve a problem that’s typically phrased as a question that looks like this: how do you work this thing (starts at 0:32)? And the solutions I provide to that problem have pretty clear value: they reduce the time, energy, and money needed to do stuff. Thus, in one way, the value of my work can be expressed as the difference between the total amount of time, energy, and money required to do a thing without instruction and the time, energy, and money required to do a thing with my carefully crafted assistance.
So I’m left with the question of whether what I do has any standalone value. Recently, though, I’ve come to the conclusion that this question just doesn’t matter. It’s intellectually lazy to think my work is somehow uniquely faced with the problem of being valueless in isolation. The work that my software developer friends do, for example, is valueless in a certain kind of isolation too. Software can’t run by itself. But should I think less of the work of software developers because it relies on the work of electronics engineers?
Instead, I now see the value of my career and all other careers for what they really are: multiplicative. Just as the work of software developers I know multiplies the value of having a computer processor, the writing I do multiplies the value of the systems and tools I write about. And so it turns out that it’s the relationship to other things that gives technical writing—and practically every other kind of work—its value, not the work itself. It’s by virtue of the relationship, not despite it, that my work is valuable.
It seems to me that what you’ve described here, by way of the scenic route, is the concept of value-added. Although you aren’t improving the product directly, your work adds value to programs and systems by making their functionality accessible. In the same way that “DOS for Dummies” allowed non-experts to get the most out of their operating systems, your work makes the subject of your tutorial more functional (and therefore more valuable) to a wide audience.