Review: The Craft of Research

The Craft of Research
Booth, Colomb, and Williamns

Engineers don’t often think of themselves as researchers. After all, what does writing a bit of code, or building a network design, have to do with research? Isn’t research something academic type folks do when they’re writing really long, and really boring, papers that no-one ever reads? If that’s what you really think, then you’ve come to the wrong blog this week. 🙂 In fact, I’d guess that a good many projects get off track, and a good number of engineering avenues aren’t explored, because people just don’t know how to — or don’t enjoy — research. Research is at the very heart of engineering.

Even if it’s never published, writing a research style paper can help you clarify and understand the issues you’re facing, and think through the options. Reading IETF drafts, software design specs, and many other documents engineers produce is depressing some times.

Can’t we do better? Of course we can. Read this book.

This book, while it does focus on the academic side of writing a research paper, is also a practical guide to how to think through the process of researching a project. The authors begin with a description of what research is, and why people “write it up.” The primary point they make here is that writing is thinking — a point with which I would completely agree. The process of building an outline and arguing a point, making certain to cover all counterpoints in the most complete way you can, is much like talking to the dummy on a more formal scale.

The second chapter dives into the mentality of writing — a very helpful overview of how to understand your audience, and then how to write to an audience. The authors take you through imagining yourself as the audience, understanding the role of the author (that’s you), and understanding the role of the reader. The third chapter probably won’t be as interesting to technical writers, because engineers are often handed their topic in an email or meeting. On the other hand, learning how to handle a topic is important. How deep do you need to go? What do you do if you find a “side question” that actually become more important than the question you were asked? These questions are addressed in this chapter and the next two.

Chapter five moves into sources — the authors provide an overview (not always as fine grained or as accurate as it could be) of various sources. They also provide a good section on thinking through alternate sources, and the problems with using people as sources. They are insistent on recording information about each source, even if you don’t think you’ll need it. I can’t recommend enough that you learn to use some form of note taking software such as OneNote for gathering information you’ve run across, even if it’s only loosely organized. I also agree with the authors here that documenting your sources is really important, even in technical projects. There’s nothing more frustrating than running across a really interesting tidbit of information and then not being able to find it again. I would recommend something like Zotero to help out with the documentation side of things.

The eighth chapter moves into structuring and making an argument. This might not seem to be important in the engineering world, but it’s actually crucial — from slides to technical specifications, imposing a logical (and narrative) structure on the information you’re presenting will dramatically help your readers understand you. Chapter nine is all about making claims — getting to the point where you make one specific point. Chapter ten discusses reasons and evidence.

The remainder of the book is focused around formatting, revising, and writing well — all worthy material, especially for engineers. This is a well written book with the lightest touch possible for a difficult to digest subject not many people know they should care about.

This is well worth reading — even if you are an engineer.