Samuel Painter

Robert Arnold
December 15, 2015

Confidence

Final Reflective Essay

On August 26, 2015, I sat through the first meeting of Intro to Technical Communication
with cautious optimism. That feeling was unrelated to the class or my expectations of academic
work that semester. Most students will take Intro to Technical Communication within their first
few semesters at a University, but I sat in class that day as a senior. That cautious optimism was in
regards to my life after school. As the semester progressed, that optimism would be challenged
and through overcoming that challenge I would develop a confidence in my technical writing that
is already paying dividends.
I was looking past the present towards the future when I was shaken by my peers review of
my work on the first assignment in this class. That first assignment was to draft a resume. The
assignment was timely as I was preparing to send in applications and meet with potential
employers; I needed to write a resume anyway. Before my peers had reviewed my resume, I had
already sent it to over a dozen recruiters, employers, and hiring managers.
My peers did not review my resume draft favorably. They pointed out flaws in its aesthetic
design, questioned the amount of detail it contained, and pointed out its lack of certain features
of a resume discussed in class. Taking these critiques to heart, I thought I may have done some
irrevocable harm to my future employment opportunities by sending out this resume that had
been so pointedly criticized. I redrafted the resume to improve its aesthetic design, reduce its
amount of information, and include all the features of a good resume as discussed within our
course text.
But I was not fully convinced that my original convictions about what my resume should be
were flawed. In fact, I continued to use a version of my original resume, along side the one that
incorporated the feedback of my peers. I had more success with the original. In fact, the
company that eventually hired me never saw the resume I drafted with their critique in mind.

!1

It was only at this point that I reflected upon the fact that I have already been doing
technical writing for years. With experience in legal writing from my time competing in and
coaching mock trial, and my experience in technical writing from my time creating
documentation for software products and communicating with computing professionals, my
writing skills, and especially technical writing skills were already sharply honed. A major theme
of this class has been writing in a reader centric way. My experiences have given me a good grasp
on who my readers are likely to be, and that makes the process of drafting a work of technical
writing much easier.
Going forward through the class I found I was well prepared for the assignments and that
they were rather easy. As the semester progressed, these experiences continued to enhance my
confidence in my technical writing ability. When I participated in group assignments such as the
instruction writing assignment, I found myself taking the lead on drafting and writing the actual
instructions.
When examining my portfolio I noticed a clear trend. The modifications that I made to my
previous drafts became less and less significant as I moved from assignment to assignment. This
was not because I took the feedback that I received any less seriously, but rather because I was
more and more confident about the initial quality of my work. To that end, however, my other
assignments received seemed to receive less and less meaningful feedback. I do not know if that is
an artifact of decreasing motivations as the semester progressed or because my underlying
confidence was reflected in an increased product quality on my part.
I have already begun working at the firm that hired me as a software engineer. Thus, I am
now in a position where I am doing real technical writing nearly every day of my life. For me,
largely, technical writing means communicating to my boss, other developers, and even clients
about the product of my work. Sometimes that means documenting my work so that other
developers, or even myself at a later date, can understand its function. Other times if means
proving the value of my work to my employer or to a client. Usually it means teaching client end
users how to use the software that I produce.
The confidence that I have gained over the course of this semester has already benefited my
work and will continue to reap benefits throughout my career. As a software engineer, I will
always be involved in technical communications with employers, developers, and clients. The

!2

quality of these communications will determine my wages, projects, and places of employment
going forward.

!3