Broken Days and Perfect Days
I read a post by D. Keith Robinson at least six weeks ago and didn't think much of it, but since then it has surfaced again and again in my mind. Robinson talks about "broken days" as a way of describing days where distractions, problems, and must-do-now crises completely disrupt productivity. Robinson says,
I call those days “Broken” because that's what they usually are. Broken by distraction, broken by too many meetings, broken by a lack of energy; these are the days where can't seem to focus on anything important and it seems like a struggle to find even ten minutes to do anything of value.
On these broken days, Robinson says you should work on small tasks that you never seem to get to.
Robinson's description of broken days surfaces in my mind when a day seems broken, but also when a day seems perfect. He doesn't mention the opposite of a broken day. I call such days "Perfect Days" — when everything seems to run smoothly, when things just fall into place. Perhaps a problem that was previously stubborn reveals itself as easy, or your understanding of a software application opens up (you finally "get it") and you write easily and prolifically about it.
I have those days at work, sure, but really my perfect days often occur when I'm with my wife and kids, and things just start clicking. I remember the first realization of my perfect day. I was sitting at a picnic table at Busch Gardens with all my family around and really feeling good inside. I thought, this must be the opposite of a broken day. Another day I was at the beach during an evening sunset, relaxing while the kids played in the sand, and I thought, life is perfect. For that hour, nothing could have been better.
We have to realize that without broken days, we can't have perfect days. So enjoy them both, recognizing that each requires the other. The more you recognize these days, which may really only last a few hours, the more content you'll be when days seem broken.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.