As a programmer, I often have a difficult time releasing my code. I always want to fine-tune it until it’s perfect, although, as programmers know, that’s usually nearly impossible given the pressing deadlines and priority shifts that can, at times, dictate our days.
I know that public relations and communications professionals can relate. So how do we know when to stop making tweaks and start wrapping things up?
Here are a few things I’ve learned from writing and editing code at AirPR that may help you avoid overpolishing to decide when to move on to your next important project.
How relevant or important is what you’re writing?
Consider why you’re creating what you’re creating. In software development, a feature may be driven by an important customer’s needs or a recent event (like Facebook’s profile-photo features that launch after tragedies such as the Paris bombings). In these scenarios, we usually don’t have the time to perfect code like we want to.
In PR and communications, you’re always considering these types of outside pressures, too. From client priorities to funding announcements, different levels of pressure may inspire different levels of polish and emphasis. If a pitch is topical, for example, you move fast to land the story, and that may mean less fine-tuning.
Consider how much your audience will value that extra effort.
When I write code, I always try to consider who will be reading it. It’s tempting to rely on shortcuts such as company-specific jargon or abbreviations, but these are only effective if the audience already has some level of knowledge about what you’re writing about.
For my coworkers who already have a wide breadth of knowledge about our codebase, it may be readable enough. But we’re a growing company and could have a new hire start at any time, and it’s more difficult for someone new to dive into code when it’s written with specific jargon.
It takes more time to write code without relying on jargon or abbreviations, but if the half an hour I spend now making my code more approachable ends up saving fifteen minutes for each new hire who looks at my code, it’s worth it.
Likewise, if you’re writing content for consumers or lay people, it can be worth the extra effort to avoid jargon so readers with varied exposure to the subject find it accessible. However, there is value to jargon: If you’re writing for industry experts or pitching certain journalists, using more technical terms might save your time — and theirs.
Will what you’re writing be important in the long run?
One of the most important considerations is the lifespan of the project you’re working on. If I am writing an experimental feature that we want to put in front of only a handful of users to gauge their reaction, I won’t take as long perfecting the code — it’s not worth the time since we might end up throwing it away.
On the other hand, if I’m working on a project that we are pretty sure will be an important or defining feature for our product, then the up-front time investment to ensure quality code is typically worth it, as it’s best to start with a strong foundation.
Similarly, a brand’s mission statement or a company’s boilerplate should be near perfect given that they inform multiple wings of the business and will live indefinitely.
Consider the law of diminishing returns.
At what point are you no longer making things better by polishing, editing, or reformatting? When is it more valuable to the business for you to move on?
Your company wants good products, but they might not want you to rework that single line of code or a specific sentence for an hour; it’s just not cost-effective. Details are important, but it always helps to keep the big picture in mind so you don’t get hung up on unnecessary perfectionism.
So the next time you’re tinkering with code, content, or communications, make sure you’re doing so with intent, not to satisfy your own itch. Focus on what matters most, even it means you’ll have to send imperfect code or a reactive blog post that’s been quickly edited live without your preferred level of polish.
Thanks, Seth. Meet another bright mind behind the scenes at AirPR:
