Writing skills versus technical skills, or, What I realized in solving a Sudoku puzzle

by Tom Johnson on Mar 19, 2014
categories: beginners

A reader recently asked,

I am a double major in English and IST at The Pennsylvania State university and I am trying to figure out how much technology I will get to learn as a tech writer. I read somewhere else that tech writing is 90% learning technology, 10% writing. What are your thoughts about how deeply you have to understand technology?

Let me respond by relating a recent experience. The other day, my third-grader brought home a 6x6 Sudoku image puzzle as homework and had trouble solving it. I had never tried my hand at Sudoku, and didn't really care much for puzzles like that. I told my third-grader that her mother would probably be better at this, but my daughter explained that Mom already tried. Mom (Shannon) noted from another room that her "brain doesn't work like Sudoku." This intrigued me, so I sat down and tried to figure out the Sudoku puzzle.

Sudoku is a puzzle where you have various sections, called nonets (or sextets for a 6x6 puzzle), that must contain all numbers 1 through 9 (or 1 through 6 for the 6x6). Each row and each column must also have an identical variety and count of numbers -- but the numbers can be in any order.

The puzzle begins with a few numbers already embedded in the squares, which you can't change. This mini 6x6 sudoku homework assignment used images rather than numbers, but we simply converted the images into numbers to make it easier.

I sat down and tried to figure it out. Shannon suggested that we cut out little tiles that we could easily shift around in the puzzle. After cutting out the tiles, we got about three quarters of the way through before realizing we were stuck. So we slid the tiles off to reset the slate and tried again, only to reach the same end.

I googled briefly for strategy info but didn't find anything. Later I tried creating an image of the Sudoku puzzle and have Google Goggles solve it (as Google Goggles supposedly can do), but I didn't have an Android device, and the iPhone Google app image search didn't work. I later found an online Sudoku puzzle solver, which easily solved it.

However, I felt empty about the computer-won victory. I thought the solution would reveal the method, but I was still just as clueless about how to solve it as before. By now my daughter had grown tired and gone to bed.

I once again googled for strategy on completing Sudoku puzzles, and this time I paid attention to the details. One guide explained how to use a "cross-hatching" technique to find the exact matches.

I'm not going to get too detailed here, but basically you draw a line horizontally and vertically through each number and see which nonet or sextet has just one empty square -- this means the number can fit only in that square for that nonet/sextet. For details, see How to solve Sudoku puzzles quickly and reliably. The following image shows how drawing horizontal and vertical lines through 1 reveals just one empty space in the top middle nonet, so a red 1 is placed there.

This method is rather tedious, as it involves doing dozens of cross-hatches (one for each number in each nonet) to determine which square is right for each number. Although time-consuming, the method does not involve mind-bending logic, just process of elimination. Within about 20 minutes, I solved the puzzle. Then I checked the solution against the computer-solved version to make sure they matched. They did.

In the morning, I showed my daughter how to solve the puzzle. She was floored to learn the strategy.

The experience caused me to think about my brain and puzzles. Although you won't find me doing any Sudoku for fun, I am engaged by challenges like this. Every day as a technical writer, I'm fascinated by little unknowns that I have to figure out. Creating code samples to address a particular situation is one way to feed this puzzle-solving/problem-solving itch. I find that my mind latches on to the puzzle/code/problem and won't let go until I've solved it.

This is one reason why I've decided to steer my career more toward developer documentation. I like the puzzle of solving code logic problems. It's much more engaging than merely editing an article someone has already written.

I also like figuring out how things work in general, apart from code. I often do relentless testing in a trial-and-error kind of way to figure out how things work. Once I figure it out, I write up a description and explanation, and I'm on to the next problem.

If I were to characterize my job as a technical writer, it's mostly about figuring how how things work. That's the fun part -- not necessarily the writing part. When I first started as a technical writer, I thought it would be a great opportunity to use my writing skills in a business setting. I didn't realize that the real engagement would be in figuring things out.

On my blog, my posts often have the same motion of trying to figure something out. I often start with a problem that I'm mulling over in my head, brainstorming ideas about it. I use writing as a tool for figuring out the solution.

Once I wrestle enough with the problem, the blog post has usually written itself. Writing is a tool for thinking, not an end unto itself. I think that's what most writers trying to move into technical writing don't get. They're good at writing, but words for the sake of words are hollow (in corporate settings at least). Few people get excited about writing an explanation of a procedure or task or some kind. But if you can de-emphasize the wordsmithing role of your career and instead focus on language and writing as a means of figuring out problems, I think you'll have a much better time in IT as a technical writer.

To come back to your original question, is technical writing 90% technical and only 10% writing? I'd say it's 90% problem solving and only 10% writing. Most of those problems are technical in nature, with varying degrees of difficulty. But it's not a matter of whether you like technology as much as whether you like problem solving.