I often have difficulty releasing my code. I want to fine-tune it until it’s perfect, although, as programmers know, that’s nearly impossible given the pressing deadlines and priority shifts that dictate our days.
I know that PR 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 decide when to move on to your next project.
How relevant or important is what you’re writing?
Consider why you’re creating what you’re creating. A software 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 cases, we usually don’t have the time to perfect code.
In PR and communications, you always consider these 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 consider who will read it. It’s tempting to rely on shortcuts-company jargon or abbreviations, but these are only effective if the audience already has some knowledge of what you’re writing about.
For my coworkers who already have a wide knowledge about our codebase, it may be readable. But we’re a growing company and it’s more difficult for new employees to dive into code when it’s written with 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 understandable ends up saving fifteen minutes for each new hire, it’s worth it.
Likewise, if you write content for consumers or lay people, it’s worth the extra effort to avoid jargon so general readers find it accessible. However, jargon can have value: If you write for industry experts or to pitch certain journalists, using technical terms might save your time – and theirs.
Will what you’re writing be important in the long run?
An important consideration is the lifespan of the project you work on. If I am writing an experimental feature that we want to put in front of only a handful of users, 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 a defining feature of our product, then investing time to ensure quality code is 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 all parts of the business and will live indefinitely.
Consider the law of diminishing returns.
At what point do you no longer make things better by polishing, editing, or reformatting? When is it more valuable to move on?
Your company wants good products, but they might not want you to rework that single line of code for an hour; it’s not cost-effective. Details are important, but it always helps to keep the big picture in mind. Don’t get hung up on unnecessary perfectionism.
The next time you tinker with code, content, or communications, make sure you do so with business intent, not to scratch your own itch. Focus on what matters most, even it means you’ll have to send imperfect code, or let a reactive blog post that’s been quickly edited go live without your preferred level of polish.
A version of this article first appeared on the AirPR blog.