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

These are a few of rants I have written over time when someone goes like ‘it works on my machine’. This helps me not going berserker and start flipping tables

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

 

1. You don’t have to explain.

People don’t need to know what are you doing and how. This includes your team leader/boss. People wanting to know about your work 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 in the repo and understand it? If it does not compile because of a missing dependency or something, 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. However, it is OK for you to demand explanations

People can’t just expect that you will go 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 are simply not. So the whole team must adapt to your style, which is the only good one. Any 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 AT ALL COST!!! This will give the rest of the team an opportunity to learn German, French or Spanish. Of course, don’t ever use Chinese, who the hells speak Chinese?

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

You get paid to write code, all that nonsense of delivering 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, it is hard… and boring too. If they want to use your code is their problem. Besides, it is really fun to see somebody else ranting about how his code is not working anymore because you changed the whole API. I really love that.

Especially good days to change the API are Fridays. This gives 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?), 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 think 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 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 pieces of advice, 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 *