After a full week of coding bootcamp, one thing (among MANY things) I’ve learned this week, is that the workflow of a programmer is much like that of a PR professional. PR and programming are industries apart — their end results differing from a featured article to a fully-functioning app — but I’ve already observed a few similarities in the ways both approach their objectives and overall problem-solving.
Work flow
Typical writing flow:
- Gather information
- Select information
- Structure information
- Translate
- Stylize text
- Format text
- Reflect on text
Typical programming flow:
- Define program objectives
- Design program
- Write code
- Compile
- Run program
- Test and debug
- Maintain and modify program
The way programmers and communications writers work, on the surface is very similar. When starting a new project, program, essay or pitch, the first step is to identify and set the goals — what kind of outcome do you want? What is the problem we’re trying to solve? What subject should the text be about?
Next, writers and programmers research and map out their plans — what should the argument in the pitch look like? What will the architecture of our program be? What types of classes or methods will we have?
Lastly, after writing our code and putting pen to paper, programmers and writers have to reflect on what they’ve put together. For writers: did we meet our goals? Will other people be able to understand our writing? Programmers should ask themselves: Does my program function as expected? Is my code well structured?
Feedback
Testing your code, over and over is imperative. Reading the error messages and understanding the output is important for us to edit and rewrite our code in order to make it function properly. If a method isn’t working the way we want it to, it’s important to understand why, and address the reason, rather than just move on with broken code.
A lot of PR is about understanding why a certain message doesn’t resonate with a particular audience. If our pitch isn’t getting picked up by journalists after pitching hundreds of reporters, its likely that we need to revisit our pitch and find a new angle to approach the media. Unfortunately, media don’t give PR people error messages… fortunately, we can ask them directly for feedback! Whether it’s emailing a journalist to see why a particular angle isn’t resonating with them, or taking them out to drinks to understand them better and learning what will resonate, reading journalists for feedback can be as simple as a program error message. Feedback with next steps can be clear as:
- “I don’t like covering [topic] because it’s not in my wheelhouse, you should try [journalist].” — pitch another journalist
- “I’m not working on a story about [topic].” / “Never pitch [topic] to me again, I hate it.” — don’t pitch this journalist on this topic again
- “I’m writing a story on blockchain right now.” — find an angle related to your company that relates to blockchain
- “That sounds interesting. Tell me more!” — learn more about the journalist, understand their personal interests and what they typically cover, tailor your communications accordingly
- “Great! I’m working on a story about [topic]!When can I interview the CEO?” — green light! set up an interview.
Whatever the feedback — positive or negative, we have typically have executable next steps that we can work on in order to get the desired results. If we continue to get negative feedback, it’s a good sign that we should change our approach to the problem and rewrite.
Coding and writing with your audience in mind
The principle of D.R.Y. (don’t repeat yourself) helps us become more effective and successful programmers. While lengthy and repetitive code may accomplish what we want, refactoring our code to be clearer and cleaner, helps others read our code and makes us better programmers overall. We’re not just programming for the machine — ultimately we’re really writing for users and programmers in the future who will build upon, extend and modify our code.
Likewise, it’s important to be concise and clear when communicating on behalf of a brand. Defining a clear argument or a statement and writing in a way thats relatable and easy to understand is key to brand communications. You wouldn’t want consumers or businesses getting confused about what your brand stands for!
code churn : lines of code
code churn = lines added + lines deleted + lines modified to a file from one file to another
I read an interesting article that proposed the 10:1 rule of writing and programming. The author concluded that the ratio of “raw materials” to “finished product” in writing is roughly 10:1 — generally on par with the ratio of programmers’ “code churn” to “lines of code” pushed to GitHub (he also found the same 10:1 ratio in film, journalism, music and photography as well).
Whether this holds true (there’s been a lot of discussion on his assertions and whether his sample size was sufficient), the point is that developers and writers have to not only hone in their craft, but also be strong self-editors to refine their end results.
Writing and Coding: Not so different
While writing and communications PR are typically seen as creative professions, and programming, a more technical one, there are certainly some similarities. Below the surface, writing and programming are ultimately, translations of high-level data and ideas, into low-level statements or sentences.