A typical writing class, at the college level, requires a couple of papers (“essays”) in an academic term. Maybe 1,500 words each, or a longer 5,000 word “term paper.” Maybe 750 (three pages) each in less demanding curricula.

 Is this wasted effort on the part of students and teachers?

 Is writing even relevant in today’s global, knowledge-worker economy?

 Judging by the resources devoted to teaching writing on most college campuses, the answer is a resounding “no.” First-year writing has been called a “ghetto of underpaid writing instructors” and faculty in other disciplines, who do care about writing, generally shake their heads and wonder why “someone can’t just teach these kids to write.” 

There is a profound disconnect, then, and those of us in the software industry see it day in, day out.

 Knowledge workers write every day than many college or high school students write in an entire term.

 We write 24/7. In chat rooms, in emails, in Skype, in formal proposals, in Requests for Work, in responses to angry customers, in agile “user stories” and “epics,” in presentations and late-night email manifestos.

 Written English is the currency of global communication; being good at writing is a competitive differentiator and a huge productivity boost. 

So to arm high school and college teachers with some evidence to support their quest for more writing instruction, and to hopefully help students understand why they should polish up an introductory paragraph for the eighth time, we’ve inventoried the writing we do in average day. The results should be head-turning for educators and students alike…

– A Day in the Life of a Knowledge Worker –

5:00am

Wake and check email, quite possibly while still under the covers, shielding the light from partner still asleep. See what came in overnight, triage, review schedule for the day. Respond to key emails with short responses, setting expectations and acknowledging receipt. Customers, colleagues, bosses, network. Personal email. Work email.

  • ~10 emails of ~20 words each = 200 words.

5:30am

Exercise. If I don’t do it now it won’t get done.

7:30am

Skype and Hipchat (chat for engineers) start to light up as the team gets cranking. Constant back and forth with product manager in Denver, offshore team in Ukraine, and core dev team in Boston. This continues until after 7pm.

  • ~75 messages read; ~25 responses = 250 words.

9:00am

Revise product roadmap in ProductPlan; intense wordsmithing to pack meaning into a small space.

  • 5 swim lanes revised = 125 very intense words.

10:00am

Product roadmap review. Team digs into user stories, the short descriptions that capture a narrowly defined goal for a particular function in software. Revise 4 stories in a collaborative session with engineers and UX (user experience) designers. Debate language for buttons that will appear in software. Revise scope of two of the user stories. Review NPS (Net Promoter Score) survey results from actual users’ rating your solution. Skype conversation continues on the side 1on1 between participants in the session.

  • 4 stories revised = 200 very intense words.
  • 3 different Skype chats = 300 informal, chatty words.

11:00am

Back to email. Compose three long messages, revising copy in a marketing campaign that will launch next month. Check on Hipchat to see what engineering is working on – the chatter goes on non-stop between Boston and Ukraine.

  • 3 emails = 600 thoughtfully crafted words.
  • Marketing copy revision = 25 very intense words.

Noon

Lunch from a food truck. Catch up on email on iPhone while waiting for order. Personal and work. Text with life partner.

  • 4 short emails = 80 words
  • 3 texts = 25 words

12:30pm

Heads-down work on next year’s budgets. Google Sheet spreadsheet – numbers, not words.

1:15pm

Break – check in on social media, including the company’s internal social network, Jive. Read 8 updates and comment on 3. Check in on industry news via Flipboard and Pulse. Email.

  • 3 comments in Jive = 150 words
  • 15 short emails = 150 words.

1:45pm            

Prep for 2pm meeting; create agenda in Google Docs

  • Agenda = 125 words

2:00pm

Meetings via Google Hangout and lots of talk. Team takes collaborative notes in Google Docs, extending Agenda with notes and creates clearly written action items in Asana.

  • Notes in Google Doc:     150 informal, shorthand words.
  • Action items in Asana:     12 action items, each ~15 words = 160 words.

4:00pm

Break!

4:15pm

Emails, lengthy Skype chat conversation, and unscheduled conversation with a colleague in NYC. Comment on UX designs in Invision.

  • 10 emails, medium and short length:          500 words
  • Skype thread extended conversation:         250 words
  • Comment on 3 different wireframes (sketches) in Invision:     100 words

5:30pm

Commute home.

8:00pm

After dinner check email before catching some Netflix and finishing house chores.

  • 5 emails = 100 words

Total Words Written:               2,500

 

This day-in-the-life describes more of a leadership role (a product manager, who leads the design and execution of ideas). Engineers, QA (quality assurance engineers), and others are doing just as much writing, but it is perhaps more informal, and they’re (hopefully) writing code.

Software development is largely accomplished these days through a process called “Agile.” The distinction here is between the Agile, newer way of building software vs. “Waterfall” – the old way. Waterfall required that the specifications for a new product had to be defined, in detail, before work started. Software is usually an art form – each project is a new creation. It isn’t mass manufacturing. No one has ever created whatever software you’re working on. It isn’t like building the same house you built last week.

Agile requires engineers receive short descriptions of work, representing very small chunks of software functionality, defined in “User Stories.”

For instance, if we were creating Microsoft Word, we might have a User Story to describe the need to Save a document to your local computer.

The User Story is written from the end user’s point of view. In our Microsoft Word example, we might write:

The user desires to save the currently open document to her local hard drive. The Save process must:

  • Ask the user to specific a location for the file
  • Ask the user to name the file (if it isn’t already named)
  • Check to see if the file exists and if the open document represents a change
  • Etc.

Engineers take these broad descriptions and choose the best way to implement in code. There are many goals for Agile, but perhaps the easiest to understand is the idea of trying to understand if you’re succeeding or failing as quickly as possible. These user stories are worked on in “sprints,” usually a week or two in duration. So the team knows, after a sprint, whether they are accomplishing anything. And they can take their small deliveries to customers and test to see if they’re building the right stuff.

In Waterfall, the way software was created before the early 2000s, someone would have documented every single function and button, then handed the design to engineering to implement. It would take months or years to know if the solutions created were of value in the marketplace, or if the project was even (truly) on schedule. Agile keeps a team nimble. No one is worrying about what needs to be built a month hence.

The irony here is that thousands of software development teams spend their day chatting on Skype, Google, and Hipchat, writing comments in asynchronous discussion such as those found in Confluence, Jira, Invision, and Jive, then project planning in Asana or Basecamp or similar. And they’re using the language of writing to organize their work.

User Stories, which describe small chunks of functionality, combine to create…wait for it…Epics.

Epics are larger chunks of functionality, like the ability to save and share documents in Microsoft via hard drive, cloud, email etc.

Part of Agile philosophy is an authentic team approach, where teams of 5 to 8 colleagues support one another. So a brilliant programmer who can’t write…can get some cover. Good writers, though, win debates in Hipchat or in Jira. And they rise to leadership roles.

So the entire software industry writes all day, in countless different ways – formal, informal, crude, and sometimes rude. And yet writing is stuck in the first year at most colleges, struggling to find relevance, depending on the kindness of strangers for its existence, just praying students write a few hundred words across an entire academic year. When the reality of modern work is that writing is central, to the tune of thousands of words per day. Where is the best place, then, to learn to write? College? Or a modern workplace? The best place to learn to write is the place where you will do the most authentic, and highest volume of writing.

Which is never going to be school, at least in today’s world. Perhaps schools should acknowledge and encourage this, pushing writing instruction into internships and supporting employers vs. trying to jam “personal narrative” essays down students’ throats.