Don't Tease the Programmer

A humorous collection of 'harmful advice' poems in the style of Grigory Oster, describing behavioral anti-patterns that drive programmers crazy — from useless bug reports to pointless meetings and constant interruptions.

Another work week is coming to an end. I don't know about you, but this week has been, as they say, a total bust. A ton of energy and brain cells spent, with zero progress to show for it. I really don't want to carry this stressful state into the weekend, so I decided to take a short break and unwind a little.

Are you tired? Want to blow off some steam? Need a breather? I invite you to join me, especially since it's Friday.

This post is about behavioral Anti-patterns. The author touched on an interesting topic about negative examples of interacting with programmers. And many people recognized themselves in these examples.

Programmers rarely initiate personal contact with users. We express ourselves in code, and personal contact comes as feedback on our software solutions. Templated behavior is explained by a natural reaction to the templated behavior of our counterparts.

All week I was forced to be the "programmer" from this article. The anti-patterns are described in the form of "harmful advice" by Grigory Bentsionovich Oster.


If something happened somewhere,
And nobody is to blame,
Don't go there, or else
You'll be the one they blame.
Hide somewhere off to the side.
Then just head on home.
And about what you saw there —
Don't tell a living soul.

Because of this kind of behavior from some users, we've had to come in to work on weekends and late at night to fix emergency outages.


If you've found a bug or error,
Write to tech support right now.
Make the subject line ALL CAPS:
"EVERYTHING IS BROKEN, DAMN IT!!"
Body text is not required,
Signature would also be excessive,
Add as many recipients as possible
And just hit "Send."

After receiving such an email, the "programmer" inside screams: "But it works on my machine!!!"


If your program has displayed
A very long error message,
Don't paste the text into the email —
Better take a screenshot instead.
Then take that picture
And place it in a Word file,
Pack it into a ZIP archive
And... forget to attach it.

It often takes a huge amount of time to extract the source data needed to solve a user's problem because of this kind of behavior.


If suddenly your program
Has displayed a message,
Don't you dare read it —
Never, not for any reason.
Call the programmer instead
And repeat word for word:
"I clicked something somewhere...
What does it want from me?"

Phone conversations with product users bring so much joy.


When speaking on the phone,
Never introduce yourself —
Start right away with screaming,
Accusations, and threats.
Ignore all questions asked,
Don't let them get a word in,
And hang up the phone immediately
Once the problem is resolved.


When scheduling a meeting,
Never forget to pack
The meeting room as full
As it can possibly hold.
It's obvious to anyone:
Twenty to twenty-five "minds"
For making a decision
Are clearly better than just one.


Meeting time also matters:
Lunch breaks are, as it happens,
Perfectly suited
For group discussions by the crowd.
We're programmers, after all —
Who needs food anyway?
Just give us a chance to chat
With upper management for a bit.


Here's another tip for companies
With headquarters in Moscow:
Evening is the best time of day
To discuss everything at length.
Schedule your video and audio calls
During this time —
Branch offices beyond the Urals
Can't wait for the opportunity.


When handing a programmer
A spec the size of "War and Peace,"
Where the table of contents alone
Takes up seven pages,
Make sure at the very end
You don't forget to clarify,
So he doesn't get carried away:
"It's like five minutes of work!"

Psychics always know in advance exactly how much time a task will take to complete.


When accepting the results
Of many days of labor,
Don't praise the programmer
Who has finished the project.
Better yet, with furrowed brow,
Make sure to let him know
That you, at his age,
Would have done it a hundred times better.


If your solitaire game worked out,
You've read all the jokes online,
Drank your coffee and don't know
What else to do with yourself —
Give the programmer a call
And ask him quietly:
"What are you up to? Oh, the project...
Well then... I won't distract you..."

Put the phone back down,
Stretch, give a big yawn,
Scratch your belly, have a think.
No thoughts? Then once again
Dial the programmer:
"How's it going? Oh, still busy...
Interesting, with what? The project?
Well, I won't distract you then."

Blow a speck of dust off your photo frame,
Move your keyboard around,
Twist the ring on your finger,
Sharpen all your pencils.
But don't get too carried away —
Don't forget about the programmer.
What if he's nervous, poor thing,
That you haven't called in a while?


That concludes this Friday post. It includes only cases from this week. If I were to recall all the situations that awaken the "programmer" inside, I could outpace Oster himself in the volume of advice. But the goal was different — to let go of the excess negativity and not carry it into next week. And it helped.

I hope I managed to distract you a little from work tasks and problems before the weekend. Smile more often!

FAQ

What is this article about in one sentence?

This article explains the core idea in practical terms and focuses on what you can apply in real work.

Who is this article for?

It is written for engineers, technical leaders, and curious readers who want a clear, implementation-focused explanation.

What should I read next?

Use the related articles below to continue with closely connected topics and concrete examples.