George Lucas Educational Foundation Celebrating our 25th Anniversary!

Technical Writing: Designing Text as an Engineer

Technical Writing: Designing Text as an Engineer

Related Tags: STEM
More Related Discussions
  • Facebook
  • Twitter
  • Pinterest
  • Share

T. R. Girill
Society for Technical Communication/Lawrence Livermore National Lab.

Technical Writing: Designing Text as an Engineer

Just what does it mean to say that nonfiction writing is best
viewed as "text engineering," as a planned and managed design
process rather than as a burst of inspiration or luck? Software
engineer Frederick P. Brooks, Jr., offers some revealing responses
to this question in Chapter 15 of his recent book The Design of
Design; Essays of a Computer Scientist (Addison-Wesley, 2010,
421 pages; ).

Brooks notes that early in the 20th century some of the best
designers both planned AND implemented their own inventions:

Edison fabricated working versions of all his
inventions in his laboratory. Henry Ford made
his own car. Wilbur and Orville Wright built
their airplane with their own hands. [p. 176]

This combination is rare today for two reasons: (1) the planning
part of design has become much more complex than decades ago,
and (2) the "implementation technology" for most inventions has
also grown very complex, becoming a full-time speciality in itself
(p. 177; chip design and fabrication offer good examples of both
trends). But this design/implementation split often causes
missed feedback opportunities and hence less practical designs.

Fortunately, student writers trying to build their nonfiction
literacy skills are in the opposite situation: they can easily
be designers, implementers, and even users of the same text.

Project abstracts provide a good example of how students can
beneficially combine all these roles. Abstracts are mostly
technical descriptions (of goals pursued, methods applied,
results achieved and assessed), so basic good-description
guidelines, like those at
give students a working checklist of issues to address as they
plan (design) their text.

But of course it falls to them to implement their own plan for
their abstract by actually drafting a prototype text. Here a
scaffold, such as the matrix at
can help students build their abstract in a top-down way:
divide the allowed space (of 200-300 words) into quarters and
"manage their real estate" by carefully filling each quarter
with interesting, relevant content (about their project's
purpose, methods, results, and conclusions/discussion

Finally, students can pretend that they are typical abstract
users as well--does their summary really take the place of a
whole paper or article about their project, revealing in
compressed form the important and unique features of their
technical work? (Of course summaries like this in their own
notebooks are literally for themselves, amplifying their own
strengths and preparing them to reuse their own accomplishments
in the future. Students really are users of their own text in
that case.)

Since student writers in science class can easily wear all of
these hats--text designer, implementer, and user--they can
nicely complete the feedback loop that Frederick Brooks thinks
is vital for thoroughly successful engineering:

...incremental development and iterative delivery builds a minimal-function version [of a
device or software] that works [this applies to
text too]; then one gives it to users to use, or
at least to test drive [p. 179].

This text engineering approach to writing and revising nonfiction
is very practical; it will serve your students well long after
any specific writing assignment or project is forgotten.

This post was created by a member of Edutopia's community. If you have your own #eduawesome tips, strategies, and ideas for improving education, share them with us.

Comments Sign in or register to comment Follow Subscribe to comments via RSS

Sign in to comment. Not a member? Register.