Skip to main content
Humanities LibreTexts

1.1: What is Technical Writing?

  • Page ID
    50678
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    What is Technical Writing

    This is a textbook about technical writing. But, what is technical writing exactly? There are any number of definitions of what exactly should or should not be technical writing, just like there are any number of definitions of what should or should not be just about anything that people care about.

    Some definitions are different because they are used by folks doing wildly different things. For example, what I consider running might be drastically different than what you consider running. For me, it’s going 2-6 miles at a pace of around 12 minutes per mile. You might run considerably slower or faster, shorter or longer, meaning that your definition of running and my definition of running differ because we are simply doing things differently

    Other definitions are different because the folks behind them have an agenda that they’re looking to push. For example, some people will stick to their position that pineapple is not a legitimate pizza topping. They stick to that definition because it is meaningful to them. For them to win out and have their definition win out is to win widespread acceptance of their position that pineapple on a pizza is an abomination. (As your author, I have no strong feelings on the subject. Pizza can have a lot of toppings. However, crockpot pizza is not pizza and never will be. You have to draw the line somewhere).

    So, since definitions different wildly, our definition of technical writing either needs to be oddly specific to the type of work we’re going to be doing in this textbook, or it needs to be fairly broad to encompass as many of technical writing’s use cases as possible. Now, either direction is going to leave some folks feeling a bit disappointed in what we’ve come up with, but I think that the most productive approach is to define technical writing in a broad way that maximizes the types of work and people that can use the term productively. This textbook is after all being designed for a course that serves any number of majors, and it makes no sense for us to play favorites.

    Getting at Technical Writing

    Technical writing, as we will be defining it, is writing that conveys information that has to be accurate in order to be of use. This may seem like an overly broad approach to defining the subject, but bear with me and we’ll tackle what exactly this means and how to unpack it, as well as some traditional competing definitions of technical writing you may have heard of or may eventually encounter.

    Let’s start with an example to show how our definition can work. If I’m going to be baking a pizza crust recipe that you’ve shared with me, there are some things that simply have to be conveyed properly or you’ll end up with a terrible pizza. If I tell you to bake the pizza at 550 degrees for 10 minutes, that is one thing. But, if you end up with a copy of the recipe that says to bake at 250 degrees for 10 minutes, you will not end up with my pizza at all. I doubt your pizza would even be edible. In this example, the technical information of how long and what temperature to bake the pizza was crucial. It could not be altered in any significant way without altering the outcome of the baking. It simply can’t work without being accurate. In short, the recipe was technical writing.

    Going beyond our example, we can expect that almost any cooking recipe would also be technical writing since you have to get things together as the recipe requests for the results to be what you’re expecting. Yes, you can alter things here or there (or make substitutions), but in doing so you are altering the final outcome away from the expected one. You simply can’t toss the recipe out the window and expect it to work. In fact, you’ll find that most folks that skillfully alter recipes are able to do so because they understand what is happening in the original and understand what their modifications are doing and how they are interacting with the original set of instructions and ingredients.

    Now, before I go further, it should be pointed out that you can take our definition of technical writing and think about things the wrong way. One common mistake that folks make with technical writing is to assume that since technical writing is about the finicky details that you simply need to convey those details as plainly as possible and you’re doing the best possible technical writing. In their mind, you’re going to be doing the best job when you simply give someone “the facts,” and nothing more. It is akin to packing something in a box and then sending it to someone else. You only put “the facts” in the box, and when they open the box, all they get is “the facts.”

    Unfortunately, this idea is not only wrong-headed—it can cause us to be terrible technical writers. The issue with a “just the facts” approach to technical writing is that the approach makes it seem that the only thing that ever matters is the facts. You can simply package them up and send them along to another person and as long as you managed to get those facts in there, everything is alright. The problem is that this example breaks down whenever you start to question it in the slightest.

    To explain what is wrong this mindset, we can actually use the same example from above with a few tweaks. For one, the way a message is packaged impacts how we respond to it. Let’s say that you package up your facts in a box and send it to someone. If we take this example literally, then we need to think about what the box looks like. Is it a plain brown box like this:

    A plain box.png

    If it is a plain brown box, does that impact your way of thinking? Do you normally get a certain type of thing in a plain brown box? I actually do associate plain brown boxes with a particular vendor I use for one of my hobbies!

    If you get a box that is wrapped in pretty paper with a bow on it, what do you think about the contents? Do you expect to get a bill for $1250 from your last emergency room visit when you open that box? Probably not. And if you did get that, you’d likely be really upset and have trouble handling that information because the box was sending one message while the contents sent another. And you’d likely get kind of mad at whoever sent the box to you this way:

    (This is what happens when you get to write an open-access book but can’t draw a bow to save your life)

    decorative box.png

    In the same way, the delivery mechanism of a message also impacts our perceptions. If we get a box that is wrapped up in a bow from a friend or relative, we expect that it is a present and likely take it gladly. If we’re given the same box by someone we’ve never seen in our lives, it might not get the same reception. We might ask, “Who is this person? Why are they handing me this gift box?” We definitely wouldn’t accept the box without some leeriness, and we might not trust whatever was inside, if we even open it at all. The sender of a message matters as much as the packaging.

    Now, if we map these examples back onto technical writing, note that the same principles apply to “the facts.” If you get a technical document from someone that you know and trust, you’re likely going to treat those “facts” with more trust and confidence because you know the text comes from a reliable source. At the same time, if you get something from someone you don’t trust, you may double-check all the information they’ve given you because you simply don’t trust them. This can also apply to the way something is packaged. If you get a document that proclaims to be super-serious and the contents aren’t, you may ignore what is included. At the same time, an official document that looks overdone or fake may get discounted as junk! Both the sender and the way contents are presented matter a great deal! (For example, awful box drawings like the one above may well get some folks to discount open-access textbooks without reading them).

    Before we move on to competing definitions of technical writing, I have one more point I want to make, because even with our examples above it could be possible that you have a few misconceptions about technical writing. In our examples below, we’re always conveying “the facts,” in our messages or our boxes. And, in those examples, it would seem that no matter what we’re still conveying “just the facts” once we cut out all the extra cruft. The essential facts never change in those examples, but when we do technical writing they very well can!

    Think about it for a moment: do you explain how to use a new app the same way when you talk to a friend and when you talk to an elderly person in your family? The answer is most likely no. There are extra steps involved in one situation, and some steps are omitted entirely in the other. The “facts” of the matter change depending on how well they’re going to be understood. You can’t simply say “this is how it is” and let things end there with someone who is so wholly unprepared to understand your instructions that they don’t even know where to begin. You have to supplement things, add content, and perhaps even alter the way you convey your points. You can’t just rely on “the facts” as a stable entity because you’ll alter their contents depending on what your audience can understand and what they know and don’t know about a given situation.

    With that cleared up, let’s return to our definition of technical writing: it is writing and communication that conveys essential information that can’t be changed without causing damage to the outcome of using that information. But, we take that with the caveat that who shares that information, they way they share that information, and who they share it to, all of these things will have an impact on the final reception of the technical information. Technical writing then, is an act of translation. We may have to alter a great many things so that our reader/recipient properly understands what we’re getting at, but we’re still trying to get them to understand the same thing we started with. It just may look a lot different after we’ve translated it for them, and they may treat it differently than they would if someone else had shared it with them.

    There is a fundamental shared value we’re all working off of—we’re not veering into total relativism here. But, we’re working with the understanding that what we know and how we use what we know is colored by who we are and how we internalize information. For example, we can all operate with the same cookie recipe, but depending on the person we cooked it with and the way they operated their kitchen and the memories we associate with them, our own mental image of that recipe can be much different than anyone else’s. The same recipe may be Grandma’s Secret Recipe, the recipe on the back of the flour bag, and that recipe you found online. Same fundamental recipe, totally different treatment of the recipe and use of it depending on your context and how you met the recipe.

    As you maybe can tell, technical writing gets intense pretty fast—I mean, we’re talking about cookies and relativism in the first chapter…heavy stuff. But, that’s what makes it so much fun to study and practice—it isn’t simple and it definitely isn’t static!

    Competing Technical Writings

    At this point, I should note that the way we’re defining technical writing may be different from other ways you’ve seen it defined or will see it defined. In my experience, our definition is perhaps overly broad compared to other versions of technical writing, but there is a reason for that broadness.

    Some folks like to say that technical writing is something that only belongs to technical fields like engineering or medicine. They might snort if you told them your grandmother’s cookie recipe is technical writing just like their specs for a bridge under construction are technical writing. That’s a problem because it limits the scope of what technical writing is and what we can study and who can study within the field. It closes off avenues of practice as much as it opens them up.

    Historically, folks have used definitions of what is or is not technical writing to control who has a seat at the table, so to speak, in the field. When someone wants to tell you what is or is not technical writing, they’re making a power play. They are attempting to define the field in a particular way, usually one that makes sense to them and gives them an advantage. Often times in history this has been used to keep, for example, the work of woman out of technical writing. We may at times be amazed (or maybe not so amazed) at the extent that people would go to in order to keep women or some other group out of a particular field, but it has happened time and time again. Again, definitions are powerful.

    So, our broad definition serves a definite purpose—to make sure that we’re not excluding anyone or anything that should/could be part of technical writing. An added advantage to that move is that we get a lot more cool stuff to study that we’d be missing out on if we limited ourselves to engineering and closely related fields. Instead, we get to look at any number of texts that are conveying technical information, often in very sophisticated ways, that have been historically overlooked by rather narrow definitions of the field. (Video game theory-crafting comes to mind as one interesting example).

    Section Break - Defining Technical Writing

    1. What exactly is technical writing? How would you define it in your own words? What are some examples of extreme versions of it?
    2. How do you define your major or field of study? What other definitions exist at other institutions? What difference do these differences in definition make? Did they impact your choice of this institution?
    3. Thinking about definitions, how are categories used negatively or positively in your hobby? Next, what is the most positive definition you can think of? How does each extreme police the hobby or field?

    This page titled 1.1: What is Technical Writing? is shared under a CC BY-SA license and was authored, remixed, and/or curated by Adam Rex Pope.

    • Was this article helpful?