DeHart 1

Sean DeHart
Pavel Zemliansky
ENC1102H
April 5, 2016
Writing as a Software Engineer

Writing with any sort of purpose can be interpreted by how the author uses parts of the
rhetorical situation. For this study I have interviewed one software engineer to see how he went
about his day-to-day writing for work and looked at the results through the lens of the rhetorical
situation to see what part of it he most focused on. There is very little information out there on
what software engineers think about during their various writing tasks and I believe that having
this information will provide insight into how software engineers write so that the next
generation has an idea of what is expected in their writing.
To gather the information used in this study, I chose to conduct an interview. Driscoll
mentions in her article on primary research that interviews are useful for gathering detailed
information from few people (Driscoll 162). A survey was also considered as Driscoll also states
that surveys can be useful to observe trends in peoples behavior which is ultimately what my
question hopes to answer. However, I felt survey questions wouldnt allow me to gather all of the
information and that I would end up interviewing those surveyed anyway. The interview was
conducted and recorded over Skype with Jeff Lup who is a software engineer in the private
sector and has years of experience under his belt. After transcribing the interview I coded and

DeHart 2

reorganized it by grouping his answers into: types of writing, purpose for writing, thought
process and preparation, and change over time. These categories I feel allow me to look at all the
information gathered and quickly find the answer I seek to my research question.
Much of the writing my interview subject reported was done for the sake of
communicating with others people about current projects. For these writings the focus as well as
the medium used changed based on who was to receive the information. For example he
mentioned that emails between group members were, a lot like text messages. You know,
short and to the point, not even remotely following grammar conventions. Emails to project
managers and other higher ups were more formal and covered more information. He also
mentioned how comments on computer code were used to communicate with anyone in the
future looking back at the code and giving them relevant information about it. Another large part
of our discussion revolved around how the type and amount of writing he did changed based on
his position (programmer, project manager, etc.). At the entry level his main job was
programming and so comments in his code made up the vast majority of what he wrote. Emails
to other team members were also frequent. Once he became a project manager he started coding
less and writing more reports and emails describing how the project was going and where it
should go next. In his words, Anything and everything happens or goes wrong, write a report,
finished something? Write a report, team worked overtime to meet a deadline, write a report.
Nearly every answer from the interview points to audience being the main focus for
writing as a software engineer. To be clear, Im using Grant-Davies definition for audience here
as he states in Rhetorical Situations and Their Constituents. The audience for a given discourse
is anyone who can interact with that discourse, whether the rhetor initially accounted for them or
not (Grant-Davie 270). When asked about his writing for work my interviewee always began

DeHart 3

with his intended audience, who he was writing for at the moment. His audience changed
everything else about his writing. For example, when writing comments in code he was working
on he knows his audience and what they expect very well (seeing as he is one of the audience in
this case). With this information he can define the constraints as well as the language he is
allowed to use. His audience expects a quickly read summary of whatever the line of code
does and understand any technical terms that could be used. While this limits what he can put
into a comment it also tells him exactly how to make it effective. We can see the effect the
audience has even more clearly in how emails change based on who is receiving them. Recall
from before how emails between other group members were like text messages whereas emails
to a project manager were much more formal even if the subject was the same. This shows us
how writings with similar content can have vastly different structures based on who the author
plans to receive them.
A focus on knowing their audience and what they expect can provide a lot of useful
information to new software engineers when writing to communicate at the workplace. Their
intended audience tells them what language and structure to use for any piece of discourse they
come across. An unfortunate constraint on this research is time. I was only able to conduct a
single interview and therefore these results may not hold true for software engineers everywhere.
Future approaches to the same question I asked here would do well to interview a larger sample
of software engineers from multiple companies and levels of experience.

DeHart 4

Works Cited
Driscoll, Dana Lynn. "Introduction to primary research: Observations, surveys, and
interviews." Writing Spaces: Readings on Writing 2 (2011): 153-174.

GrantDavie, Keith. "Rhetorical situations and their constituents." Rhetoric Review 15.2 (1997):
264-279.

Lup, Jeff. Personal Interview. 26 Mar. 2016.