Inb4 sorry if this is cringe or whatever

We don’t do code review

At my previous job a coworker left positive comments alongside any negative ones on my code. “Nice job here. Very clean”, or “nice use of X design pattern here!” Kinda made me look forward to his code reviews.

The commonly touted "best" experiences are when you just get told "wow, this code is amazing!"

I hate those code reviews.

The best ones are the ones where I get my code completely ripped apart by 10 different people in 10 different ways. Some of them might be amazing. Some of them might be arseholes thinking slating other people's code is how you climb the career ladder. But they all generally teach me something, and they all cause me to stop and think "hmm, have they got a point, or is my original design better?" The discussion that comes from those reviews is also often very interesting; and (when done well) the whole process can become somewhat of a teambuilding exercise for everyone involved.

What?... really?... You read my code? ...*wipes away tears*

THANK YOU SO FUCKING MUCH!!! You sir/madam/undefined are a true gentleman and scholar! (even if you are just a troll picking random shit apart to flash around your superior knowledge of design patterns).

Any time I receive a code review, that is bearing that is an actual review, born of free will and not a mandatory report - I feel flattered beyond words.

> Think its shit? - GREAT FINALLY FEEDBACK!
> Have an idea? - I'm all ears.
> Trying to sound smart? - You still read/used my shit.
> Want to understand my approach? - Grab a drink and get comfy son.

In a world where I am usually the only person in the world that knows WHAT MY ACTUAL WORK IS and there being only a select few people on the planet able to understand it, I am always grateful for developer feedback.

Seriously... out of your own volition you used my code, read it, made an effort to understand my thinking and THEN REACHED OUT TO ME with ideas!!??

I could kiss you... you beautiful binary saint.

My best code review experience?

Company hired a new department manager and one of his duties was to get familiar with the code base, so he started rounds of code reviews.
We had our own coding standards (naming, indentation, etc..etc) and for the most part, all of our code would pass those standards 100%.

One review of my code was particularly brutal. I though it was perfect. In-line documentation, indentation, followed naming standards..everything. 'Tom' kept wanting to know the 'Why?'

Tom: 'This method where it validates the amount must be under 30. Why 30? Why is it hard-coded and not a parameter?'
<skip what it seemed like 50 more 'Why...?' questions>
Me: "I don't remember. I wrote that 2 years ago."
Tom: "I don't care if you wrote it yesterday. I have pages of code I want you to verify the values and answer 'Why?' to all of them. Look at this one..."

'Tom' was a bit of a hard-ass, but wow, did I learn A LOT. Coding standards are nice, but he explained understanding the 'What' is what we are paid for. Coders can do the "What" in their sleep. Good developers can read and understand code regardless of a coding standard and the mediocre developers use standards as a crutch (or worse, used as a weapon against others). Great developers understand the 'Why?'.

Now I ask 'Why?' a lot. Gotten my fair share of "I'm gonna punch you in the face" looks during a code review, but being able to answer the 'Why?' solidifies the team with the goals of the project.

The company I work at sends their developers out to other companies to help them work on projects and help them in other ways (advice when communicating to customers of on demand software for example).

While not on a project you are working in house training trainees and interns. Part of that is teaching them to show initiative and treating them as full developers. The 30 interns all discussed a git flow and code format.
During the third sprint (two weeks sprints) a team messaged me if I wanted to check their merge request for the sprint.

It took me a glance at the first file to know they didnt do any review themselves. I used my flywheel to check all their changes and without being able to read the code I saw indentation was all over the place, inconsistent bracket placements etc. I let them know I wouldnt check their code until it was according to their own standards.
Two days later I got the message to check it again. At first glance the indentation was fine so I started reading the code. Every single thing was hardcoded, not made to support mobile (or any resolution other than 1920×1080).
A week later they improved it and still not good. Gave them a few pointers like I would for any colleague and off they went to fix things. The code became worse and indentation was all over the place.

I told them the next time it shouldnt be a quick glance to be able to reject it again. By this time other teams came to me asking why it wasnt merged yet and I explained it to them. One of the teams couldnt do anything u til this was merged so I told them to implement it themselves. I was surprised that 4 teams came to me asking about a merge request, that was every team except the team whose pull request it was.

4 weeks after the intitial sprint the other team made a merge request and I had three small comments and then an hour later it was merged.

The other team messaged me why their merge request did went through (still havent seen any of their team in person, Im sitting 10 meters away from them behind a wall)
They also said that it was easier for them because they started from scratch. Thats when I called them in to discuss it all and if they were not interns but full time developers they would have been fired. I told them communication is key and that if you dont understand something you come in person to ask about it. They all knew I like teaching and have the patience to explain a single thing ten times, but the initiative should be theirs.

One of the team members is my current coworker and he learned his lesson by that. The others stopped with their study and started doing something completely else.

TL;DR
Merge request is open for 4 weeks, in the end another team started from scratch and finished it within a week. The original team didnt ask me questions or come to me in person, where other teams did.

DISCLAIMER: some of you might find it harsh, but in our experience it works the best for teaching and we know when people don't dare to ask questions and we help them in that too. It's all about the soft skills at our company.

code review? you mean 2 people sitting at one laptop, trying to figure out where the bug is?

I prefer pair programming over code review.

Reviewing the code of my then new CTO, who said "I can also code and have experience in Java" - 50 lines of code, I added over 30 comments to his Pull Request. In the end, I rewrote his complete code.

Code review?......... what's that?

Joke apart, We literally don't do that in my workplace, only few people care about code quality and what they are pushing to production

When I started my internship my PRs got absolutely blasted by code style comments and suggestions about code that could be more optimized

Now, almost a year later, I can proudly say my PRs only get a maximum of 2 comments and I've seen myself grow over the months :)

I once had to review and transform the code of one of my colleague at school which had no indentation, no spacing and was a clusterf*** of syntax errors. The nightmare was that it was all done in the ancient Turbo C++. So I opened up plain ol' Notepad and whipped up some decent code and helped him out of a tight situation.

Now he is no longer a programmer. :|

When someone actually commented on my pull request, rather than just clicking approve without reading it.

My best code review was when my merge request was accepted in less than a minute after creation. It was simple but I expected more time on review and accept action.

To understand recursion, just click these links:

Best code review experience was when I was mentor in a bootcamp and I had to review code from scholars, they were surprised by how their code could be written in less lines.

We only recently started and we can really see the benefits of code review.

It motivates you to follow the standards, writing good quality code and using variable/function names that makes sense. Especially that you know someone is going to read through it.

My best review was when i changed the code that someone suggested in another PR, which was highly critiqued by the OG devs. One pull to the latest commit and PR to his fork later, the OG dev comments "that looks good" and merges it.

Celebrated for sure that night. I've been hooked on contributions to open source ever since.

Comment out all the code.

Almost every I code with close friends (all seniors) or my brother (also senior).

It's crazy what we can accomplish when there is no implicit and no one want to take shortcuts.

And mostly on personal projects, no client to shit all over the place.

With m'y brother we also often code at 4 hands in repl.it

When I get one with constructive feedback. It's rated since I'm usually the one that tells people their code sucks.... After it causes a production issue.

Yes no one does a proper code review on my direct team.... Just the stuff a linter would tell you to fix....

How to get these swags?
How many do you possess?