Book Review: The Hunger Games, and a Possible Parallel for Technical Writers
The Hunger Games, by Suzanne Collins, is one of the most suspenseful page-turners I've read in a while. I actually listened to it via Audible, and I was so pulled into the story that I found myself doing dishes, cleaning up, driving slowly -- anything so that I could prolong listening to the book. A couple of nights I stayed up past 1 am listening to it wide awake in bed, unable to sleep.
In brief, the book is a dystopia set in the future, with a teenage narrator (Katniss Everdeen) passing through enough violence and tension to noticeably increase your pace of breath. Set in the future, the Capitol requires that two children from every district (there are 12 districts) participate in a death-by-elimination game in a large arena. Each child must try to kill the others -- the last one standing wins. As the game lasts a couple of weeks and is set in a wilderness spanning several square miles, there are plenty of deadly unknowns and surprises in each chapter.
Although the book kept my attention, the technique used in practically every chapter seems to be the near-death experience. It's as if the narrator tells us, I almost died, but then I lived. Though simple, it seems to work. From giant "tracker jacker" attacks to extreme hunger to deep cuts from knives to "muttations," the narrator keeps alive in the Hunger Games until, well, I don't want to spoil the ending, but let's just say the first-person point of view doesn't suddenly stop.
Another technique in the book is the way Collins ends each chapter. She ends it on a cliff hanger that compels you to the next chapter, in much the same way that episodic television ends with a cliff hanger, drawing you back for more. With the chapters, this device pulls you further into the book, because just as you plan to finish one chapter and then rest, you realize that you can't stop reading. It's a great technique for novelists to adopt if they want to add more suspense in their writing.
Genres and Themes
Although The Hunger Games is young adult fiction, my wife won't let my six-year-old or four-year-old listen to the recording. And my ten-year-old, who read the whole trilogy and then listened to the Audible recording, said she wouldn't recommend it to anyone under 12. I actually didn't think it was too violent to restrict it from these ages, but I may simply be desensitized.
The Hunger Games fits in with a trend of dystopian novels in the juvenile genre. With the Hunger Games, the dystopia provides an immediate evil (the Capitol) that the protagonist can work against. Because it's simply a dystopia, set in the future, we don't seem to require much explanation to justify the state of things, other than knowing a few wars and rebellions led to it. Without the dystopian framework, the writer would have to work harder to get the reader on board with the idea of a sinister government organizing barbarian games with children for entertainment.
Parallels with Technical Writing
Since nearly every post on my site needs to tie back to technical writing in some way (or readers complain), I offer almost as a footnote to my review a parallel between technical writing and the Hunger Games. The following idea is somewhat fragmentary, and a bit of a stretch, but nonetheless partly true.
In the Hunger Games, the Capitol does a stellar job at restricting communication between districts. As a district member, you never hear of uprisings or unrest going on outside of your district. The Capitol will filter out any negative rebellion, they will quash any act or disruption that doesn't support the Capitol. As a result, the people in the districts live in a world where information is sanitized and restricted, and where their voice doesn't matter. Every media outlet is a cleaned up funnel of pure propaganda for the district. And the restriction of information paralyzes the people with inaction.
Not to unlike the Hunger Games, documentation has often been the puppet voice of the company. In documentation, technical writers spin things positively, more often stating what you can do rather than what you can't. Technical writers are quick to remove any hint of failure or shortcomings about an app. If a bug exists, or if a process is cumbersome and technical to the point of absurdity, the documentation will not reflect this with an honest voice. It will instead stick with an objective, official style, glossing over any kind of explanations that would undercut a praiseworthy display of the product or its creators. Rather than admitting poor design, or insufficient coding, or some other bungle, technical writers filter all this out and describe the application with a tone of achievement and possibility. We are part of the corporate propaganda machine.
As a technical writer, are you another "peacekeeper" of the Capitol?