Rant: How to work in collective in order to keep things NOT working

To avoid going berserker and start flipping tables, these are a few of rants I have written over time when someone goes like ‘it works on my machine’.

So here you have it, a few guidelines and bits of advice if you want to slowdown your team, stress the sh**it out of them and become the ‘gem’ of the company.

 

1. You don’t have to explain.

People really don’t need to know what are you doing and how. This especially includes your team leader/boss. People wanting to know this are nosy and gossipers who had no life. No matter their claims about the need for collaboration. If they can’t use your code is because they are so stupid they can’t read your code. I mean, is really that hard find your code out in repository project the project and understand it? If it does not compile because of a dependency missing, there is always Google and StackOverflow. If they want to inspect your work then go ahead and read the code. They don’t have to ask you. This constant demands for talking only reduces your capacity to write code. Which is ultimately your goal in the team.

2. But is OK to demand explanations

People just can’t really expect for you to go out and read their code. Is not your work to read somebodies else’s code, right?. That’s their work. If they want for you to cooperate with them, then they must give documentation, explanations, and presentations. Otherwise, you have all the right to sit in your hands and claim that they don’t communicate.

3. Git is magical

What the hell are all these rules for committing and versioning that we have in the team? Git is made by Linus Torvald. It should work. Always. Period. If not, is simply because the whole idea of versioning is wrong. I’ll send you the code by email and you do the merge manually.

4. Indentation and style rules are too much

This one is so simple to understand that it really bothers me when other people just don’t get it. Your indentation, naming, and style of code are beautiful and readable. Other’s people is simply not. So the whole team must adapt to your style, which is the good one. An imposition on this direction is an abuse of power and a clear manifestation of a non-equal opportunity employer.

5. Comments are useless

Future programming languages are going to be written without comments. That’s a fact. So we better stop using them so we can’t make the transition easier. However, in the hypothetical case that you MUST write a comment in your code, AVOID ENGLISH!!! This will give the rest of the team an opportunity to learn German or Spanish. Of course, don’t ever use Chinese, who the hells speak Chinese?

6. Your job is to write code. Nothing more.

I get paid to write code, all that nonsense of the suits to deliver solutions and so on… bleh! My code works on my machine. If it does not work on your machine is because you have some configuration problem.

7. Maintaining backward compatibility slows down the progress

Don’t maintain backward compatibility, it slows down your creativity. Is hard… and boring too. If they want to use your code is their problem. Besides is also really fun to see somebody else ranting about how his code is not working anymore because you change the whole API. I really love that.

Especially good days to change the API are Fridays. This give your teammates something to do on weekends, so boring in general. If they don’t check the unit tests on Sunday (yes some people don’t check tests on Sunday, can you believe it?), is amazing to see their faces on the Monday meeting with the Architect. I really love when they babble “this was working perfectly when I left…”. Hilarious.

8. Normal languages are boring

So your team wants to use a normal and boring language such as Python, C# or Java? Poor souls who have lost the spirit of innovation and adventure. Certainly, those languages have a lot of documentation and there is a library/framework for almost everything you can imagine… but that’s precisely the fun part of new stuff, that you get to reimplement a linked list in a new paradigm! Obviously, the project will take more time and money. But managers only thinks about money (they should be like me, I never think about money as long as I get my paycheck at the end of the month) Managers, as I was saying must never, under any circumstances, restraint the rebel genius in their programmers.

Conclusion

These are my suggestions to make yourself the ‘most loved’ guy in the office. If you follow these advices, I can assure you that they will be talking about you in every coffee break, even if they never invite you to one.

Leave a Reply

Your email address will not be published. Required fields are marked *