How to Piss Off Other Programmers
How to Piss Off Other Programmers
Charlie Munger, the Vice Chairman of Berkshire Hathaway, is known for a quote where he says “Invert, always invert: Turn a situation or a problem upside down. Look at it backward.” There’s actually more to the quote, but I want to focus on those first two sentences, because it’s a useful way to look at almost any problem. As software engineers we’re expected to act professionally and be a team player in our day jobs. Basically be a good person. Sounds easy, right?
Most of the time it is, and just being a good person will get you far in your career, but it’s easy for us to forget what that means sometimes. We get caught up in tasks that take longer than we thought, or we ignore other tasks because we’re working on something more interesting. Sometimes we just get lazy. It happens to all programmers, and in most cases we do this without even realizing.
Unfortunately when we do these things, we may be upsetting our team members without even knowing. So rather than give you advice on how to be a good team player, let’s invert the idea and look at things you can do to piss off other programmers. By turning the advice upside down, hopefully you’ll be more aware of it next time you find yourself doing one of these things.
Include changes in your pull requests that were not part of the ticket’s requirements.
Write one or two short sentences for your testing instructions on your pull requests.
Don’t include automated tests on your pull requests.
Work on things that are low priority.
Refactor code that they wrote without consulting them about it first.
Call them out publicly for something wrong with their code.
Refuse to take the boring bugfix tickets.
Don’t follow coding standards.
Don’t review your own pull requests for bugs or typos before tagging them on it.
Ask them questions that can easily be found in the documentation.
Ask them questions that can easily be found on the first page of a search engine.
Ask them the same question multiple times.
Don’t do the thing they ask you to do.
Don’t do the thing you told them you would do.
Start coding up a solution before reading the ticket description that includes important information.
Don’t help out when there is an active incident.
Blame them when there are bugs in production, even if they were responsible.
Talk bad about them to other software engineers.
Use design patterns in your code when they aren’t needed to solve the problem.
Refuse to work on tickets because you don’t like the programming language or framework.
Write functions that are 500 lines long.
Write Classes that are 5000 lines long.
Don’t write any documentation.
Ignore security risks because you think you’re too small to be a target to hackers.
Ask them to fix your build.
Hard code secrets or environment specific logic.
Write useless commit messages that give no information.
Ask them why your code isn’t working.