A flashback from my internship

A few months ago, I was an intern at Facebook:

I had the opportunity to work over there three months in this amazing project I’m not allowed to talk. But one of the things I like and dislike the most was the process called Diff Review.

If you have work in Github on collaborating work you may know it as Pull Requests. This process is the one where you submit your code so someone from your team can check what you did, ask questions or for changes, or simply admire what beautiful code you wrote.

I love this process because it helps a lot to know what everyone is working about, at least in my case, when I didn’t know much about how things work at Facebook, but it gave clarity on what everyone was working.

On the other hand, the people that know what they’re doing in the team, they have an opportunity to check what you have done, and by this, you can improve and learn from the advice they can give you.

I love the diff review system because all of this, it helps me in a way to improve as a developer, but as a matter of fact, this wasn’t the first time I did this.

My first time was in my Facebook University internship, but we sucked at it because, in my team, everyone was too lazy to review, so we accepted everything, you can check that out if you’re curious in the repository.

A funny story of this is that we submitted our API keys, and we panicked and had to contacted GitHub support for them to remove our mistake.

These mistakes were one of the reasons I enjoy the review process well implemented, but I hate when no one wants to review your code. This is the opposite of just accepting it without at least looking at the changes.

What I did had a lot of mathematics, and my team though they didn’t have enough knowledge to check the math, so they avoided it, this was a bad praxis because of that block my progress a lot of times. Another fun fact (and somehow sad), on my last day there was one commit pending for review, it blocked all my other commits, I finished my internship and didn’t push it to the codebase even after they review it, because there was a bug in the platform.

In general, the process of code review in teams, well-implemented, is excellent and has its pros, but if the team doesn’t commit to scheduling some time to work on code reviewing then the process is useless.