Use `console.log()` Like a Pro & How to create a healthy code review process

I saw this tweet the other day and left it aside to read it later.

Use `console.log()` Like a Pro: https://t.co/amWg5HbO2p

— JavaScript Daily (@JavaScriptDaily) December 1, 2020

I won’t lie to you. I don’t code a lot. I code as less as possible. My associate is way better than me and it’s just not really my thing. But I still deal with a lot of code for projects and I have to understand it or to review it. The best way to do it, for me, is to jump in the code read the comments and try to understand it. Sometimes even with the comments I’m not quite sure how some of the code works so I console.log() my way in it. This article by Marko Denic just made me realised that there is more than just the console.log() which I sadly didn’t know/forgot. But more than that reading about this subject made me think about our intern process of reviewing code.

So I went digging in that subject and I found this article:" How one code review rule turned my team into a dream team"

If you’re able to cut trough the bullshit there’s some interesting takes on the subject. The main point I will personally take is the following:

Each PR must have a good description. From reading the description, the reviewer should be able to understand what the code is meant to do. This has to be true even if there is a Jira ticket or a requirements page.

It’s really something we must work on. I don’t know if it’s laziness or inexperience but as of now we are mostly skipping trough this kind of rule. We make a good requirements page and we think the code won’t need good comments and good PR description. The fact that our team is small and that we can directly talk about any issue makes it less needy of those rules but only if everything goes right. If my associate is sick or decides to take another job, then it will be trouble.