Information Technology Reference
In-Depth Information
taken seriously. Last, a piece of personal advice: be confident that you are willing to
do the work. A commitment to a project that you find unrewarding may not lead to
strong outcomes, and is likely to undermine your commitment to other activities.
Non-technical Writing
Professional computer scientists have specific expert or technical knowledge in their
areas of competence. They apply this knowledge to produce materials such as soft-
ware and technical descriptions of software. However, this material often has to be
explained in a non-technical way, that is, technically-informed writing can be for a
non-technical purpose or a non-technical audience.
System requirements and user manuals are an obvious example. But there are
many other circumstances in which professionals and researchers need to write for
non-technical readers. For example, management may be seeking a recommendation
as to whether to proceed with a particular project, and need to understand the benefits,
options, costs, and risks. Expert evidence to be placed before a court has similar
characteristics; it needs to be technically precise, but, often, must be written for an
audience with little domain knowledge.
For example, a company might need to decide which workflow tool to purchase.
The IT unit is asked to prepare a recommendation. This is likely to consider factors
such as cost, reliability, support, and the vendor track record—elements that are no
different from any other purchase. But technical factors are also likely be impor-
tant, and need to explained: choice of server platform; functionality; obstacles to
compatibility with existing systems and applications; and the method of adoption.
Can it be gradually introduced, or must it be a sudden cut-over from an existing
application?
And then there are pragmatic considerations, which for examplemay flow from the
preferences or capabilities of the IT staff rather than definite technical grounds: will
the code be developed under Microsoft
R
Windows or Linux?Will it be browser-based
or stand-alone? And so on. A responsibly written recommendation should be open
about the influence of such considerations, and about their implications and costs.
I've observed that these kinds of writing task are more challenging than just
about any other kind of professional communication. They demand more skill than
is required when writing for colleagues, who have the advantage of working in a
common framework; they also require imagination, for example to create illustra-
tive descriptions that concisely explain concepts that may be alien to the audience.
Even fundamentals can be difficult to communicate. Consider, for instance, how you
might describe
software architecture
,
type definitions
,or
open-source development
to an attorney. And then consider how you might explain—in writing, and without
an opportunity for face-to-face conversation—that a certain online data collection
process is error-prone because of how Web browsers manage state and identity.
A key to taking on such tasks is to approach them much as you would a research
paper, as described in Chap.
5
and elsewhere in this topic. Write early, and be willing
