The Value of Tech Support to Software Engineers

by Mark Bernstein

My day as a software engineer always starts with tech support. Morning e-mail brings news from writers in Europe who have run into problems, from West Coast students who are trying to puzzle out their reading assignments, from scholars who ran into trouble with their research notes long after midnight. Nearly all of these will be new questions about new problems. This is especially true today, because this week we're finishing a release of Tinderbox, our tool for visualizing, analyzing, and sharing notes, and the beta testers are poking at rough edges.

Today brought a bad file from Indianapolis, documentation clarifications from Portsmouth (accompanied by notes on preparing a  lobster and scallop risotto to be served with vinho verde), concept mapping queries from Oxford (with plans for a historical novel), and a proposal for a new feature that we'd never considered, that has never appeared in the research literature, and that appears to have occurred to this user on his first day. The post brought a large enigmatic poster, accompanied only by a hand-typed Rolodex card, which we presume is the first step in an elaborate author query, and a book jobber's order for a single copy of a hypertext novel.

As an industry, we have mixed feelings about tech support. We all pledge allegiance to user-centered design, to customer-driven development, to getting products out quickly so buyers can tell you how to improve them. But we also go to great lengths to shield developers and designers from tech support, lest their time be swallowed in a general clamor. Phone trees and callbacks and screeners are so effective that most of our new customers simply assume that tech support is a hollow promise.

Users are great at finding problems. Users are plentiful; they try surprising things; they sometimes have whimsical ideas about how the software works. Listening closely to tech support gives you a good sense of what needs to be polished and how your software is actually used. It also reminds you how much the software matters to people's work and how hard people's work actually is.  

Mark Bernstein is chief scientist at Eastgate Systems, where he crafts software for new ways of reading and writing.

Presented by

James Fallows is a national correspondent for The Atlantic and has written for the magazine since the late 1970s. He has reported extensively from outside the United States and once worked as President Carter's chief speechwriter. His latest book is China Airborne. More

James Fallows is based in Washington as a national correspondent for The Atlantic. He has worked for the magazine for nearly 30 years and in that time has also lived in Seattle, Berkeley, Austin, Tokyo, Kuala Lumpur, Shanghai, and Beijing. He was raised in Redlands, California, received his undergraduate degree in American history and literature from Harvard, and received a graduate degree in economics from Oxford as a Rhodes scholar. In addition to working for The Atlantic, he has spent two years as chief White House speechwriter for Jimmy Carter, two years as the editor of US News & World Report, and six months as a program designer at Microsoft. He is an instrument-rated private pilot. He is also now the chair in U.S. media at the U.S. Studies Centre at the University of Sydney, in Australia.

Fallows has been a finalist for the National Magazine Award five times and has won once; he has also won the American Book Award for nonfiction and a N.Y. Emmy award for the documentary series Doing Business in China. He was the founding chairman of the New America Foundation. His recent books Blind Into Baghdad (2006) and Postcards From Tomorrow Square (2009) are based on his writings for The Atlantic. His latest book is China Airborne. He is married to Deborah Fallows, author of the recent book Dreaming in Chinese. They have two married sons.

Fallows welcomes and frequently quotes from reader mail sent via the "Email" button below. Unless you specify otherwise, we consider any incoming mail available for possible quotation -- but not with the sender's real name unless you explicitly state that it may be used. If you are wondering why Fallows does not use a "Comments" field below his posts, please see previous explanations here and here.


Photos of New York City, in Motion

A filmmaker animated hundreds of still photographs to create this Big Apple flip book


The Absurd Psychology of Restaurant Menus

Would people eat healthier if celery was called "cool celery?"


This Japanese Inn Has Been Open For 1,300 Years

It's one of the oldest family businesses in the world.


What Happens Inside a Dying Mind?

Science cannot fully explain near-death experiences.

More in Technology

From This Author

Just In