search

websages / hates-software

Site for hates.software
http://hates.software
MIT License
2 stars 0 forks source link

Issue to track ways of getting out of work. #1

Open jameswhite opened 6 years ago

jameswhite commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

The massive overhaul

Also known as "The Mines of Moria"

bval commented 6 years ago

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 commented 6 years ago

The Stack Overflow

The N+1

bval commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

The raspberry beret

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

stephenyeargin commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

The Pomodoro

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

stephenyeargin commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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

like, re: Sam text Editor

cc @bval

stephenyeargin commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

The Fuck It

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

rick commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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.