How to Sabotage Your Team: A Guide to Pull Request Pandemonium
Are you bored at work and want to rustle up some division within the team? Is everything running along a little too smoothly for your liking and you feel it would be fun to throw a few spanners in the works? Are your team mates irritating you and you want to get back at them with some good old fashioned passive aggression? Then I have some great tips for you! (Assuming you’re a Software Developer and you work with a team doing Pull Requests… if not then you will just have to divert to ChatGPT and ask him/her/them what are some good tactics for team destruction in whatever field you happen to be working in. I’m sure it will come up with some great suggestions).
The following “tips” are for when you are working on Pull Requests. Pull requests are a necessary evil in the software world.
Software Developers love to work alone, huddled over their laptops in dark rooms with streams of fluorescent green text shimmering up and down their monitors. That’s a fact.
However, on occasions they have to peer out from their murky dens and ask their fellow Software Developer to look upon what they have just created and deem whether it fits the standards of the greater team.
It is at this point that you can commit your stealthy sabotage of the team’s ever fragile and tenuous bond. Team leads and managers are constantly coming up with ideas about how to strengthen this bond and preach about the ‘Velocity’ and ‘Productivity’ of a well-formed team but you know better. You know that Software Developers work better alone and this whole idea of a ‘team’ is some deep government conspiracy to coerce us into giving up all our privacy and personal sovereignty.
So here we go!
Make PRs unnecessarily large
This is an easy one to achieve. The team have agreed that it’s a good practice when ‘A PR focuses on one thing and one thing only’. Maybe so but it also seems a little slow and tedious when you can add 5 different things to a single PR.
Ideally you want to pick things that are totally unrelated because that will only help confuse the reviewer even more. If you’ve been tasked with updating some code to do with a user profile, then make sure you also change some code that is concerned with an item page. If you been tasked with updating a pipeline then make sure you change some code on the UI.
And when your changes are questioned by the reviewer (as it no doubt will be) then defend your decision aggressively. Make up some nonsensical connection between the CI CD pipeline and the UI and justify your decision. The sabotaging has begun…
Add broken tests to your PR
This is a good one too to slow down the so called ‘Velocity’ that the pompous PO is always going on about in stand-ups. Software developers love tests. So in this approach you are being extra sneaky by pretending to tow the line but really you are acting as a deviant saboteur.
Add tests that deliberately break and also testing for absolute nonsense. This can actually prove deceptively tricky to implement especially with those pesky DevOps guys who have set up their fancy pipelines that catch all broken tests before you can even put the PR up for review.
But this is where you must persevere and show some creativity. You are a Software Developer after all! Even if you just get the reviewer to highlight the tests are broken, it’s still a small win as you are chipping away at that delightful ‘Velocity’ goal.
If your team doesn’t have checks in their pipeline then you can go to town. Over time you could add dozens and dozens of broken tests and render the whole testing implementation absolutely useless.
Don’t add any description to you PRs or better yet write nonsensical sentences
There is nothing more irritating than going to review a PR that has no description. No link to an issue. No text. Nada.
So use this to your advantage in your plot to bring the team to an absolute standstill. Don’t add any descriptions to any of your PRs and then see what kind of feedback you get. Once you have had enough feedback about this then swing completely the other way and add massive descriptions (this is where Generative AI can actually be useful) and make them super long and elaborate and really difficult to read.
Put the wrong labels on your PRs
This one is really getting petite but very easy to accomplish and good for causing mild irritation throughout the team. Whenever you add a bug fix PR then label it as a ‘New Feature’. Whenever you have a improvement then label as a ‘Documentation Change’. Some may call this ‘Childish’, I prefer the word ‘Playful’.
When reviewing PRs either approve everything really quickly without comments or leave hundreds of really pedantic comments that are not useful
As part of a team you will also have to review code and this is where you can become a real nuisance. Whatever you decide to do, you have to be extreme in your approach. Floating down the middle will not get you results and this is a results based game we’re playing.
Approving PRs really quickly without any comments may make your popular with some team mates in the short term but it won’t take them long to realise that something isn’t quite right. They think their code is good but surely it can’t be that good? It’s all mind games.
Alternatively, go with the approach where you leave hundreds of comments on each PR. It’s another chance to show your creativity. Here are some examples to stimulate your creative juices:
- “This could be written in a slightly more efficient way, but it’s fine.”
- “Fix this.”
- “This variable name is stupid.”
- “This is completely wrong. Do it all over again.”
- “I don’t like this.”
Merging Without Approval
This is a great one to gain you popularity points amongst your team mates. Create a PR and then merge it straight away before anyone has had a chance to review it.
Is you work in an organised team you may be scuppered in your plans by rules setup on your code base which don’t allow PRs to be merged without at least one approval. In which case this plan won’t work very well. Boo DevOps for spoiling all the fun. However, if you are in a team where these rules haven’t been set up then merge away!
Conclusion
It’s obvious to see from this list just how simple it is to cause disruption and frustrations within a Software team. Even one bad apple can spread disharmony throughout a team and a disharmonious team is not a fun place to work in.
Obviously the tips in this article are not to be followed because if you did I am sure your time on that team would be extremely short lived (albeit an entertaining ride).
It also highlights the fragility of the whole Pull Request process and if certain details haven’t been addressed or thought out in the team then problems can quickly surface.
If you have any horror stories of working with difficult team members on PRs then please share in the comments.
Subscribe to My Weekly Updates!
Enjoyed This Post?
If you found this blog post helpful, why not stay updated with my latest content? Subscribe to receive email notifications every time I publish. New posts go live every Monday at 8:30 AM Central European Time.
What You’ll Get
By subscribing, you’ll get:
- Exciting Discoveries: Be the first to know about the latest tools and libraries.
- How-To Guides: Step-by-step articles to enhance your development skills.
- Opinion Pieces: Thought-provoking insights into the world of frontend development.
Join Our Community
I live in the vibrant city of Prague, Czech Republic, with my family. My blog is more than just articles; it’s a community of like-minded developers who share a love for innovation and learning.
About me
I’m a passionate Frontend Developer specialising in React and TypeScript. My professional journey revolves around exploring and mastering new tools and libraries within the JavaScript ecosystem.
Check out the original blog post on my blog.
