5 Practical Tips on How to Bloat Your PRs and Annoy CoworkersA Guide for Designers Who Code

Cover Image for 5 Practical Tips on How to Bloat Your PRs and Annoy Coworkers

I am a designer, but I am of the kind that likes to get his hands dirty on the UI and make sure I’m doing the best use of the tools provided by the platform. I spend countless hours playing with UI Kit, game engines and web.

Last couple of jobs I took, the managers were so open to new ways of working that they decided that I could actively and consistently contribute to the codebase. That was a great learning opportunity, both for me and my colleagues. This post is about me, but mostly about them.

Here is a practical guide on how to make sure your PRs engage with coworkers for you. Beginning with, use your PR to:

1 “Fix” unrelated code from another feature

As my senior developer always says “There is nothing better in the morning than waking up to broken tests on CI.” That’s why you should always try to make amends for your past mistakes (occasionally of other people as well) and fix every piece of code that seems wrong. Once I accidentally enhanced defaced the animation of a flagship feature trying to make code better.

2 Add tons of unsolicited documentation

Reading is fundamental, and there is nothing better than stating the obvious with your documentation. Is there a better way to turn a 10-minute code review into a spelling and grammar challenge than to add all the documentation you like to that asset change on the corner of the screen‽ It can help your coworkers flex those language muscles and ensures that everyone is aware os what you have to say.

3 Add Storyboards files

I’m sorry, this one was priceless. Simply start using Storyboards, there is no better way to make a small PR turn into a tentacled sea creature than that. They are notoriously hard to merge and will provide an endless amount of hours into XML-land.

4 Enhance unrelated code for an upcoming PR

Yeah. Keep that game going by adding to how the app works and making sure it is ready for your next PR. There is nothing better than preluding some change you intended to make on future code.

5 Overcomplicate a piece of architecture

Ever since I came into contact with some very modern protocol oriented stuff, I learned that every single class can have a same-name protocol by its side; for example: SomeData and SomeDataType. I went completely overboard with it and decided that every single thing I put on the codebase would have a protocol oriented flavor to it.


These are not actual things you should be doing with your PRs, but a list of honest mistakes that I have made and learned from my inclusion into the development process.

I know satire is not my strong suit, but it’s mine.

Other blogs