Keep Two Thoughts

Personal essays


Immediately - Essay from Newsletter 117

What’s the rush

Two phrases

As I continue my descent into being a crabby old man, there are two phrases I see and hear in reporting that drive me nuts.

The first is “unquote”.

I was taught to use “end quote” or “close quote” and I appreciate outlets that do. Most, unfortunately, end a quotation with “unquote”.

Unquote.

Like they’re taking it back.

Use end quote because you are ending the quoted text or close quote because you are closing the quote you opened.

Unquote.

Sigh.

The other is that a source “did not immediately respond to requests for comment.”

I know what it means but it doesn’t say what it really means.

In its most kind reading it means that we asked the person for a comment and published the story before we heard back from them.

I read it as an admission that they know that responsible journalism requires a comment from this person - or at least a request for comment - and they went to press before they got it.

It always make me stop and consider whether the piece needed to be published at all - as often the details missing loom larger than the ones included. If you’ve got nothing to add to the story everyone else has written, what are you doing?

It also seems to paint the person who didn’t respond as being at fault. Like somehow it was their responsibility to respond immediately.

I warned you we are in crabby old man territory - but “did not immediately respond” jars me in the same way that “unquote” does.

Immediacy

So much of what we do rewards immediacy.

The advice of the person who speaks quickly with confidence is often sought out before that of the person who needs to quietly consider all aspects first and perhaps talk it over with someone.

With all the benefits of Extreme Programming and the concentric feedback loops, it wasn’t for everyone. I had friends that just didn’t like pair programming. They loved sharing their code with others and getting feedback but they just didn’t think well while sharing a keyboard because they felt a quick answer was over-valued.

They weren’t trying to buck anything - but no system is perfect for everyone. Some people do better in the office and others do better remote. I’ve read a lot written recently by people on each side of that divide on why their side makes more sense.

The most vehement lately have been by people arguing that the job they do can only be done in person or that it is important for the company culture.

Perhaps.

I think it also depends on the people in the jobs. Some thrive in an office and some work better at home. Most likely the truth lies in between. I found I did best when I came in monthly or quarterly and met with people in person as it helped shape the voices we used when we read each other’s emails or otherwise collaborated at a distance.

Back to pair programming.

I spent a few days working for a company that had an absolutest policy about pair programming. They felt that pair programming was the only way that code could be written.

I don’t mind pair programming. I find it a bit exhausting but I don’t mind it. I think it’s great for some people and understand its benefit for sharing knowledge of a project. I just don’t think it’s the only way.

At this particular company, it turned out, I was wrong.

We were working on an app for an insurance company and there was a bug in the program that was causing the program that was on the app store to crash.

I woke up one morning with one of those feelings you get when your subconscious mind has worked something out overnight. I went to my laptop and was able to locate the problem and fix it and check it in.

I was off that day so I didn’t go into work but I sent a note that I’d fixed the bug, told them how and where, and wrote that I would see them the next day.

The next day I went in to work and found that the app was broken again.

Instead of checking my code and accepting or rejecting it, it was rejected out of hand because it hadn’t been written in a pair and all code had to be written in a pair.

No one looked at the discarded code and besides it wasn’t really my job to fix the bug.

Co-workers wondered why I left the job that morning.

I was not immediately available for comment.

Delay

Really good news outlets will check back with the sources who weren’t immediately available and update the story once they get a comment or answers to some questions.

Most move on.

If we don’t get an answer immediately, something else shiny will come along to capture our attention.

The newsrooms are understaffed and the bad news keeps on coming.

The reporters who used to have time and resources to report a story now also serve as their own photographers, write and update articles for the online edition, and record podcasts.

Not immediately available? We’re moving on.

And the sources know that. If they keep themselves from being immediately available then they know the story moves on.

It would be nice if the paper would print, our source “never gets back to us ever so don’t hold your breath.”

It would be nicer if the paper would print, our source “got back to us with a reply that was so thoughts-and prayers banal that we couldn’t waste your time with it.”

Unquote.


Essay from Dim Sum Thinking Newsletter 117. Read the rest of the Newsletter or subscribe


See also Dim Sum Thinking — Theme by @mattgraham — Subscribe with RSS