Code-review is completely overrated and not worth the time it takes. For me, I’d rather use that time to tell some jokes with my colleagues, go grab myself a coffee or do some meditation to heal my inner soul from the bugs that I fix all day.
For some weird reasons, code-review is becoming an integral part of the development process in companies nowadays. Therefore, I’m coming in today with a few tips and tricks for you on how to screw that damn code-review.
1- Reinvent the Wheel
Yes, you read that right. Please reinvent the wheel.
Last week I wanted to buy a tire tube for my bike. I went to a bike shop, headed to the tires section, and started decoding all these crazy numbers trying to find the right tube for my bike.
There were many types and brands of tubes. One of them — to my surprise — was a tube that heals itself in case of a puncture!
Question: Isn’t that reinventing the wheel?
I paused for a second and said to myself; if the person who invented this tire listened to all the bullshit being said about reinventing the wheel, I wouldn’t have had this fancy tire right now.
I bought the tire. And learned the lesson.
And you should too!
Discourage your mates from using any third-party libraries, even when it makes sense. Ignore all the “This library has been tested by millions of people” or the ”why waste my time while it already exists?” kind of sayings. Trust only yourself and always start implementation from scratch!
2- Performance? No, thank you. We don’t want!
Are you an actor? Are you a singer?
If your answer is „no“, then you don’t need to care about „performance“.
What is the big deal about 100 queries instead of 1 query? Why care about the difference between half a second or a second. Do-you-know-that-you-spent-now-at-least-three-seconds-to-read-this-statement?
Please have no regrets to turn anything the looks like this:
string query = "SELECT * FROM users WHERE id >= 1 AND id <= 100";
Result result = orm.execute(query);into something that looks like this:
for (int i=0; i<=100; i++) {
string query = "SELECT * FROM users WHERE id =" + i;
Result result = orm.execute(query);
}3 - Automated testing does not exist
Can a machine actually test a machine? Let’s think about that for a second…
If that’s true, then the machine (the latter) will also test another machine (because a machine tests a machine), which in turn will need to test another machine… wait a minute! That’s an endless recursion.
Congrats! You have found a bug!
To solve this bug, praise your colleague when s/he ignores about testing, never do the mistake of reminding them of writing tests. Promote human QA instead and stop the robots from taking our jobs!
4- Bury Exceptions (TBD)
Developer: I always deliver my tasks on time.
Manager: Did you deliver the task you were supposed to deliver yesterday?
Developer: hmm, no ….. But by the way, that is the exception that proves the rule!
Manager: **** ***!
Would like to hear these words from your manager? I bet not.
Throw exceptions, but this time out of your code base. And if you can’t do that, then bury them and put them on silent, so that at least you could enjoy a good night sleep.
5- Encourage Technical debt.
The good thing about being a dictator is that you don’t need to seek any kind of approval from your people on anything that you do.
In order for a dictator to survive and keep chair, s/he (c’mon it is usually a “He”) would need to pay lots of money to his supporters. To do that he has two options: 1) Borrow money from friend countries. 2) Subscribe for an “Economic reform” program with the IMF.
while (iAmAlive) {
if (friendCountries.notEmpty()) {
money += friendCountries.pop();
} else {
money += imf.hitMe();
}
}The above code is provided “as is”, with no warranty or liability on the author in case of running it and turning into a dictator. Use it at your own risk.
Either way, this will leave the country in huge debts. And the good part is; the dictator will not be held accountable for that when he leaves his chair (usually happens when he dies btw).
By the way, I already know one dictator who does this. Oh, did I say one? I think I know 10…
We developers should act like dictators (you already have the recipe above). We need to take as much debt as we can. Why? Because we can always leave the job and not be held accountable for that debt. We can start fresh in a new place with zero debt!
6- Favor sexy over readable code.
Imagine if you could build your whole application in 3 lines of code. Only 3 lines of code!
Your whole product catalog, the checkout page, payment gateway integration, even the success email that you send to the customer upon ordering — which alone is longer than 3 lines of text — is already contained within these 3 lines of code that you wrote.
Wouldn’t it make you a genius developer? Wouldn’t everybody be so fascinated by you and say they are glad they have had the opportunity to work with and learn from you?
Yes, they will do.
Ditch readability, flush the toilet over maintainability and abide by spaghetti to achieve prosperity!
7- Good things smell
If you couldn’t write sexy code, don’t worry. Going the other extreme is also fine, and can sometimes be even better.
Research always says; Human brains are hardwired to stories.
A great keynote speaker will always have a story to tell. A successful salesman will bind his product to a story to make it appeal to more customers.
And we developers should tell stories too!
But since we developers don’t like to talk too much, what would be a better place for telling your story other than your IDE?
Think about this one:
bool youChangedINeverThoughtYouWouldDoThisToMeIDontThinkYouLoveMeAnymore = true;One variable = one short story! …. Isn’t that amazing?
Now look how boring it would be if we took out the smell:
bool youChanged = true;
bool youDidThatToMe = true;
bool youDontLoveMeAnymore = youDidThatToMe || youHaveChanged;With the smelly style, you will not only find it easy to express yourself and your emotions, but you will even have the choice to publish pieces of your code as stories if you like, and earn more money ;)
Accept only fat functions that have no less than 5 parameters, which would, in turn, lead to chubby and fluffy classes. A little bit of code duplication here and there would give your story more essence.
Stop … Don’t trust this … I was kidding. Now let’s be serious.
In fact, code-reviews are really important. Besides the fact that they serve as a way to have a second eye on code before it goes live (this could prevent real problems), they also foster a positive development culture within the team based on good communication and healthy criticism, which in turn lead to more success for the team and the product being developed.
Therefore, please don’t screw code-review. In other words, please do the complete opposite of what you read until now:
- Don’t reinvent the wheel — Promote the usage of already-developed libraries.
- Look beyond the mere implementation of a feature and think about performance and security.
- Automated testing helps you spot problems before the shit hits the fan.
- Let exceptions bubble to surface so that you know as soon a problem happens.
- Avoid technical debt — or at least have a plan how to fix it in the cases where it is a necessary evil.
- Readability is important for maintainability.
- Avoid code smells.