Issue to track ways of getting out of work.

[jameswhite]

We've all got co-workers that avoid work. Hell, sometimes we avoid work. Append comments to this issue with the kinds of techniques people use to get out of work and we'll give them all names like "the Jeff Bunch Maneuver" or whatever and put up a pages site.

warning: These comments may trigger some PTSD

Cc: @rick

[jameswhite]

The Linux Laptop

The user refuses to use the laptop you shipped them and instead of doing work, spends most their time fighting linux laptop problems such as dotfiles, auth, vpn, and many many more. Every day is a new linux problem that's keeping them from getting those tests to run or getting that code shipped.

[jameswhite]

The +3000/-3000 whitespace PR

The user spends a week cutting a PR that changes no functionality other than putting whitespace after equal signs or bumping 20 gems a patch level It takes a hour to review and there are absolutely no substantial changes to any functionality in the code.

[jameswhite]

The Public / Private communication split

This one comes in a few variations, but in essence it's a disparity between what one says or does publicly and what they say or do privately

Variation 1: the Jeff Bunch

The user tells you in private that thing their waiting on isn't important so don't rush. In the next all-hands they announce they're blocked by the thing they're waiting on from you.

Variation 2: Let's Pair on it

The user announces in the group meeting that they really want to do something but need help pairing on it. Once you start pairing with them on it, they're dismissive and cut the pairing session off early because they "can handle it from here." Nothing ever gets shipped

Variation 3: Houston, we have a problem:

The user is super vocal about solving something in the group meeting. They immediately hit a problem and then DM co-workers individually to ensure they know about the issue, but refuse any help. The problem persists until the next stand-up. Nothing gets shipped.

[jameswhite]

The convenient sick-day or appointment

The user ships nothing all week. On the one day that you have a meeting to discuss blockers / progress, they're out sick. The following week they ship just enough to get blocked on something, they report they're blocked in the next meeting, and are conveniently sick the meeting after that.

[jameswhite]

100 conferences

The user is away at a conference 2 weeks out of every three, but they'll have their laptop with them in case you want them to not work from the conference.

[stephenyeargin]

Blocker Detector

Within a short period of time starting on a project, has created or found a blocker that they believe must be resolved before any work at all can be done. Casual observer believes problem solving would allow it to be bypassed. Status updates center around the blocker, which becomes increasingly intractable with every telling, while simultaneously refusing assistance to resolve. When applied to its logical conclusion, project is canceled for lack of interest.

[stephenyeargin]

Pet Project

Has a pet project, either of their own creation or an executive's, that always has higher precedence than whatever work needs doing. The project has unclear objectives or utility to the business as a whole. User will volunteer to help with other work, but when asked for a status update, the Pet Project has sucked away all their available time and they were unable to help. They are sure to mention that they worked on your project during status updates in spite of their contribution being little more than "looked at it for a second."

[stephenyeargin]

The Council of Geniuses

Management has elevated one or more team members to be the spiritual leaders of the group and to extol the virtues of shipping code. Council member posts random Hackernews articles to Slack and does a lunch-and-learn once a quarter, but never ships anything. Often has title of "architect."

[jameswhite]

The massive overhaul

Instead of shipping value to the business, the user ships massive projects like openstack or kubernetes that never really land and add value to the business, but that entire team looks super-busy (overworked, even) while shipping this Big Thing™ That basically ships the exact same capabilities the company had before the project started. If it fails massively, the team can just change jobs and put this item on the resume so they can go do it somewhere else.

[jameswhite]

The "Get back to work, james"

User spends more time babbling in chat slack/irc/hipchat/commenting-in-issues than shipping code.

Cc: @heathseals

[stahnma]

I don't do Windows.

The developer or team builds something that only works on Linux/Mac even though the requirements clearly stated Windows as a need. They're days away from shipment and they say, "I don't do Windows. I guess you should have made time on the Windows team to do that." And now the project turns out half-done.

[rick]

The Ant Man

In standup the developer gives a status report that talks about the minutiae of what's being worked on, especially any "blockers" in such high level of detail that people start to stare out the windows; gets cut off eventually in the interest of ever ending the meeting. No work has actually been done.

[rick]

The hoarder

After going away in the corner for a few days, no work is visible. When asked where the Pull Request is, the response is some variation of "I've got it on a branch". When asked to push the branch, developer says that they are trying to get everything working before pushing it up.

[rick]

The massive overhaul

Also known as "The Mines of Moria"

[bval]

The Stack Overflow

Developer cannot be bothered to develop the feature, and so adds a 30 KLoC Javascript library to the project to facilitate the one-line implementation he found on Stack Overflow. This took a week but as a bonus the PR is +30,001.

[ccollins]

The Stack Overflow

The N+1

[bval]

The perpetual rebase

The developer has been working in a branch and cannot push it because there are too many conflicts with master. Hold please while he works to catch his branch up to master.

[stahnma]

Displacement Activities

I would have done that, but I didn't have time. I was busy at the Green Certification meeting, the Company Foundation Charity Ball planning meeting, the community volunteer day planning lunch, and the recognition ceremony for the person who has been here 30 years but refuses to retire.

[jameswhite]

Invisible information gathering

The user is "collecting information" for documentation or some other process but is doing it where no one can see the outline nor the notes collected. Even in high school you had to submit the outline and rough drafts

[bval]

The Great Axe Sharpening

Developing the feature will require a whole new toolchain. The time is spent playing with learning new tools, which are added to the build for no gain, and there is no time left to develop the feature.

[shrug]

The Reef Builder

We're blocked because toolchain is too reason. So we must use {rust|go|clojure|swift|whatever} if we're going to build newthing. Rinse and repeat for every new feature, leaving the pile of tech debt behind you as you go.

[jcockhren]

Meetings about Meetings

Too busy meeting to get work done. Usually due to willfully ignoring the option "no" in response to "I'm gonna set up a meeting" or "Do we need to set up a meeting?" queries.

[jameswhite]

Meetings without agendas or take-away action items

Schedules meetings where there's no defined thing to decide or disseminate and there's no work decided upon nor assigned by the end fo the meeting. It's just a bunch of people talking with no result.

[azizshamim]

The "Top Priority"

Priorities change every N-1 days, where N is the number of days required to complete the task. End result, nothing ships.

[rick]

The raspberry beret

I was busy doing something close to nothing but different than the day before.

[stephenyeargin]

The software updater

Purposefully updating the host operating system and various dependencies right before a deadline to create the perfect storm of compatibility issues, rendering the user's laptop an expensive paperweight. Debugging is nearly impossible, as StackOverflow hasn't caught up to that level of fuckery yet.

[stephenyeargin]

The foil-baller

Every configuration, patch and dependency has been quietly added to the production fleet without any semblance of configuration management or source control. One wrong move and any one of the foil-balls will fall off, leading to a cascading issue that only the Foil-baller can hero and fix. We are starting to think they knock them off on purpose to avoid productive work ...

[stahnma]

Let's take this offline

Critical decisions must be made, but rather than make them and have an effective meeting, somebody just suggests we take an item offline. Then no follow-up ever occurs and thus the only decision that was made was that we're not currently making a decision.

[stahnma]

The Meta Discussion

Rather than do the work, talk about the process of doing work. Evaluate process, look into how work happens rather than what work is happening. While this isn't always a bad thing, it's great to bring up when results are missing.

You can ask for guiding principles, beliefs and values, and for systems-level thinking about the problem.

[stephenyeargin]

Compiling

As demonstrated in XKCD, there is always some long-running process that prevents further work, such as but not limited to: waiting on a firewall rule from operations, installing nokogiri (and probably failing), waiting on Docker images to pull, or VM provisioning in general. User has developed a skill at having an excuse and a not-moving console at the ready.

[maxbeizer]

The Left Turn

The complement to the Let's take this offline, a Left-Turner will wait until just before the important stuff in a meeting is about to get discussed and will take things in a totally different direction that ensures the important stuff never gets addressed.
"Are we here to resolve X? Great! Let's talk about ß (a whole different alphabet) in excruciating length and detail before we get to it! Is it related? Who cares?

[maxbeizer]

The Pomodoro

Wherein one never gets any work done due to the need to take frequent breaks in the name of productivity.

[stephenyeargin]

The Potato Passer

No matter the task, there is always somebody else who should be doing it instead of our user. This tactic comes in two variants: hot potato and cold potato. The hot potato passer will throw a ticket to somebody on the team within moments of getting it, claiming that surely another person has more time or experience with the issue referenced. The cold potato passer waits until either immediately before a due date or right after being asked for a status to pass the proverbial potato.

[gpadak]

The one-way street

When your job is to pass product information from the engineers to the salespeople, it's not good enough to simply get the right information to do your job. You need to get it from someone who is process-empowered to give you that information. For instance, if the process says an engineer should tell you what's being built and a salesperson tells you instead, you should discount everything that salesperson says because they're not supposed to know before you tell them. If you don't get it fast enough from the engineer, then it's 100% not your fault and you should complain about the broken process while everyone else tries to meet shipping deadlines.

[jameswhite]

The I'm struggling but don't need help

User complains that thing they're trying to do is "hard to get their head around" all attempts to educate the user fall on deaf ears or are immediately deflected so that it can remain hard and thus will take longer, delaying shipping.

[jameswhite]

The process pedant

When fulfilling requests the person utilizes any method available to ask for more information, ask that a particular process be used, ask forms to be re-submitted, so that the fulfillment (the actual work) can be delayed indefinitely, even when the intent can be clearly derived from the request.

[kpaulisse]

Saved by the meeting

User starts work on something and then runs into a difficulty. The user has to go to a meeting, so they throw the work out to the rest of the team to pick up, never to return.

[northrup]

The Key Jangler

User would work on something if only they had access. They could grant themselves access as part of their role, but chose instead to block themselves by trying to delegate.

[stephenyeargin]

The Helpless Pair Programmer

Variant of "I'm struggling but don't need help," but where the need is indeterminable.

While pair programming has proven benefits in building better software, there are times when it can be abused. User spins their wheels for a period of time (or at least, appears to) before declaring the problem unsolvable and saying they can finish it if, and only if, somebody will volunteer to pair on it with them. Pairing session ends up being mostly watching somebody else finish their work while they feign amazement. Pattern repeats until nobody falls for the trap anymore, with "couldn't find anyone to pair with on it" being the excuse for work going unfinished. Management faults unsupportive team instead of deficient programmer.

[gpadak]

The Product Pushback

Even with a clear product spec on what needs to be done, the engineer would feel much better if N+1 customers have validated the decisions that have been made, which forces the product manager to continue customer development. This virtually guarantees at least one more day that the engineer doesn't feel responsible for scoping execution work on the project.

[jameswhite]

The Royal You

An urgent issue comes about. User immediately jumps into the conversation to give their thoughts about how severe the issue is, and offers "We should fix this!". They quickly hop back to their pet project or head to a dentist appointment and you're left realizing they actually meant "YOU should fix this!". User returns in time to claim some or all of the credit.

[jameswhite]

The Stand-Up Pinball Wizard

The most important thing is to deceive people during the standup. You need to make everyone think you're working with other people, that way it's difficult to track and verify what you're doing. Create a diffusion of responsibility so no single individual feels responsible for calling you out.

It helps if you volunteer for tasks that don't require work, like volunteering to QA things everyone knows don't require QA. Or claim you did a manual verification of something, when you actually did nothing. If it ever comes back to bite you just say there was some confusion.

Always schedule meetings, always talk about scheduling meetings, always structure things so your work is blocked without that pointless 'sync up' meeting. The trick is to always make it seem like progress is being made.

For example:

• Monday: Get assigned a task
• Tues-Wed: Be "examining the requirements" and scope of the task
• Friday: Report you've got questions about some of the details of the task. Talk about scheduling a meeting with the task creator. They'll agree. Schedule the meeting for Tuesday.
• Monday: Report that you've got an upcoming meeting with the task creator
• Tuesday: Report your meeting with the person in standup, but then privately message task creator and postpone the meeting using any excuse, probably because you "want to investigate some more details first". Reschedule it to Friday.
• Wednesday: Announce the meeting got postponed because of newly discovered details. This helps keep the appearance of progress.
• Thursday: Sleep in, you've earned this one
• Friday: Meet with the task creator. Make them walk through the history of the issue, even if it's not relevant. Nod and smile, you're not really listening anyways. At the end of the meeting thank them profusely, as if they've unblocked you and relieved a massive burden from your plate.
• Monday: Report the meeting was useful, and you're going over notes from it. You'll get asked if you have everything you need, or if you're blocked. Never report you're blocked or else your manager will get involved and uncover how trivial this is.
• Tuesday: Report that you're making changes as discussed in your meeting, and things are good
• Wednesday: Report you expect to have a changelist out today, this will buy you time until Friday.
• Friday: Take Friday off
• Monday: "Yeah, I have some additional questions for the task creator. I ran into complications"
  Tuesday: "I'm scheduling a follow-up meeting to address my concerns"
  Wednesday: "We chatted on Slack yesterday and it was useful, I still have some additional questions"
  Friday: "I'm meeting them on Monday to follow-up"
  Monday: "I'm meeting them today"
  Tuesday: "Yesterday was useful, I expect to have a changelist out tonight"

etc etc for as long as possible

1-2 weeks later, the task creator gets fed up and does it themselves. After all, it'd their product, it's them who are ultimately responsible for the success of it. Why should you care? They switch a single test value from true to false, and the task is complete without you having done anything.

Loudly talk about your collaborative effort. Seize upon any doubts, questions, or related feature complications as reasons why it took so long. Obscure truth of your involvement via "we" whenever possible.

If the task owner is in your standup meetings they should be left impressed at your bold distortion of the truth. But their civility and politeness should prevent them from publicly calling you out. After all, any single event can be waved away as a miscommunication. Spread this behavior across as many team members as possible to delay the accumulation of suspicion.

[hortoncd]

The Hurry up and Do it For Me. I can do it myself? It's fine, I'll Wait.

Very concerned that this thing they opened recently hasn't been done yet by the automation, etc. When you let them know it's set to be picked up, but they have the access to do it themselves if they need it quicker, it's suddenly fine to wait.

[rick]

I can no longer ship software until I learn this obscure af editor from Plan9

like, re: Sam text Editor

cc @bval

[stephenyeargin]

The Kanban Optimizer

Leaves several tickets unresolved in the project software (even if they are complete) so as to prevent other tasks from being assigned. PM avoids assigning new work so as to prevent subject from being "overloaded."

[rick]

The Waiting Game (h/t @DanHoerst)

Requests a review from a specific person or team not likely to see or be in a position to provide the review in a timely manner, hence blocking themselves for longer than if they had just requested a view from the team, reviewers, organization at large, etc..

[ccollins]

The Fuck It

The company clearly has no viability, so grifts as much as possible until the end

[rick]

The Spinning Top

Company leadership has no real direction so has frequent (every 6 weeks, every month, every other week, etc.) "strategy" sessions, or otherwise frequently revamps how work is done, tracked, planned, reviewed, retrospective'd etc. Down tools each time to "get on the same page". Bonus points if a new tool (notion, linear, jira, github projects, leankit, etc.) is introduced frequently to replace the old tooling and processes which "just aren't working", and time is taken to "bring everything forward" and "get used to the new system".

(I include this strategy because I've seen it in real life, and inducing this strategy can effectively get one out of work indefinitely, while fucking around with new toys)

[DanHoerst]

The Weekend Release

I don't know enough about this project, nor do I care to learn. Therefore, we should release it on a weekend so that if it fails we can hide our incompetence in this area as much as possible.

cc @hortoncd "and by we, I mean you"

[DanHoerst]

The Debug Draft

I'm debugging a problem and "I want you!" to help me, now. Rather than put my breadcrumbs in an issue or a thread, I'm going to spam my debug progress across all kinds of different Slack channels. The many folks who are interrupted by these messages will have no choice but to participate in the debugging with me. With my army of debuggers, they will work through the issue and I will regale my superiors with the tale of how I solved this impossible problem.

[rick]

Come in so jaded your peers are like "this person is great", then ship nothing and ingratiate yourself to management.

[stahnma]

The Yak Shave plus Quality Goals

Person 1: Oh, I started working on that, but looking into it I found this other problem. It then led to another investigation where found our libraries were out of date. To fix that, I had to upgrade the OS. I can't upgrade the OS until later this year, so this fix is on hold.
Person 2: Do we need new libraries and OS to make this change?
Person 1: No, but if we don't take any pride in our work it will all be shit. You don't want a mountain of tech debt do you?

[stahnma]

Idealogical Purity

Person 1: This fix requires a foundational change to our domain model and how we build our software.
Person 2: Couldn't we just add a new field to that table in the DB?
Person 1: Sure, you think that will work now, but will it work forever? We need a whole new service to enable the CRUD operations of this field, and with that, an extensive integration with our observability tooling and security sign off. So, I estimate this taking about 4 months minimum.
Person 2: But we literally could just add a field to the table.
Person 1: You just don't get this, do you?

[stahnma]

RIIR

Every modification of software spawns a discussion of how we must Rewrite It In Rust (RiiR) due to the safety and awesomeness that is our lord and savior Rust. Thus to make any change, you must find a non-believer.

[stahnma]

The Coffee Spill

You "accidentally" spilled Coffee/Soda/Water all over your desk and keyboard so you're computer isn't really functional today. You're letting it air out and dry off and hoping it work tomorrow.

For extended usage, it doesn't work tomorrow and you have to order new parts.

[gdonald]

The non-TDD'er

You say "Almost done, just need to write some tests" at every standup. You writes minimal tests that pass by accident. Code ships but gets reverted.

[thephw]

The support ticket armada

Producing a huge amount of support tickets about trivial speed bumps while continuing to get no actual work done. Not my fault the vendor doesn't do things the one way I think it ought to work.