DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Managing Changing Hardware/Peripherals in a Robust Point of Sale System
  • Beyond the Resume: Practical Interview Techniques for Hiring Great DevSecOps Engineers
  • From Algorithms to AI: The Evolution of Programming in the Age of Generative Intelligence
  • What Do You Mean by Debugging in C?

Trending

  • Data Integration Landscape 2026: Event Streaming, API, and Batch in the Era of Agentic AI
  • How to Format Articles for DZone
  • Fix the Target, Precompute Once: A Backend-Free Word-Ladder Solver With a BFS Distance Field
  • Part 3: End-to-End Tracing and Observability Across Goose, agentgateway, and Quarkus

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

The Passive-Aggressive Programmer (again)

By 
Steven Lott
·
Jun. 02, 12 · Interview
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
12.8K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in
I'm not even interested in psychology.  But.  This kind of thing seems to come up once in a great while.

You're asked (or "forced") to work with someone who—essentially—fails to cooperate.  They don't actively disagree or actively suggest something better.  They passively fail to agree.

In fact, they probably disagree.  They may actually have an idea of their own.

But they prefer to passively "fail to agree."

I have little patience to begin with.  And I had noted my personal inability to cope in The Passive-Aggressive Programmer or Why Nothing Gets Done.

Recently, I received this.

"I thought I was going crazy and started doubting myself when dealing with a PAP co-worker. I went out on the internet searching for help and ran into your blog and its helped me realize that I'm not crazy. The example conversations you posted are almost every day occurrences here at my job when dealing with my co-worker. From outside of the department it was oh those two just butt-heads because I never knew how to communicate or point out that really I'm a targeted victim of a PAP rather than a butting heads issue. No matter what approach I took with the PAP I was doomed and still not quite sure where to go from here. Would you happen to offer any advice on how to actually deal with PAP? It's driven me to a point where I'm looking for new employment because my employer won't deal with it." 

I really have no useful advice.  There's no way to "force" them to agree with anything specific.  In some cases, there's no easy to even determine what they might agree with.

Your employer will only "deal with" problems that cause them real pain.  If you're butting heads, but still getting things done, then there's no real pain.  You're successful, even if you're unhappy.

If you want to be both happy and successful, you need to stop doing things that make you unhappy.  If you can't agree with a co-worker, you can butt heads (which makes you unhappy) or you can ignore them (which may make you happy.)

Ignoring them completely may mean that things will stop getting done.  You may appear less successful.  If you stop being successful, then your employer will start to feel some pain.

When you employer feels pain, they will take action to relieve the pain.

You might want to try to provide clear, complete documentation of your colleague's ideas, whatever they are.  If you write down the Passive-Aggressive Programmer's "suggestions", then you might be able to demonstrate what's causing the pain.  Since a properly passive programmer never actually agrees with anything, it's tricky to pin them down to anything specific.

You might be able to make it clear that they're the roadblock that needs to be removed.
Programmer (hardware)

Published at DZone with permission of Steven Lott. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Managing Changing Hardware/Peripherals in a Robust Point of Sale System
  • Beyond the Resume: Practical Interview Techniques for Hiring Great DevSecOps Engineers
  • From Algorithms to AI: The Evolution of Programming in the Age of Generative Intelligence
  • What Do You Mean by Debugging in C?

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook