8 comments

[ 2.9 ms ] story [ 31.0 ms ] thread
I've had very good experiences with reviewing complex changes with less experienced dudes. You have to approach it with a different mindset though.

With more experienced guys, I give them code and they fire back "Yo, those 10 things look bad, those 8 things are easy problems, those two things are probably broken, and you turned your brain off in that test".

Less experienced team members can be intimidated by code and standing and you have to overcome that. But I've had great experiences by handing them change sets, give them some time to read it until they are ready and comfortable to ask me questions about it and to tell me what it does, and then we just talk about the code.

This resulted in a really cool situation. I was working on a lock-free, cache friendly tree implementation in java and had relaxed a couple of locks and it was some really tough stuff. So we ended up talking about style, and then digressing into explanations of java memory visibility, concurrency, lock-free algorithms, several square meters of whiteboard painted over several times, and then this girl says "Yeah so if I get this right your code is slower than it could be, and wrong in a case. Let me show you". And she was right, and I was floored.

This is probably a bit off topic but I'm curious:

> then this girl says "Yeah so if I get this right your code is slower

How old were you and how old was she? And where in the world was this? For comparison I'm a British man who has lived in Norway for the last 32 years and I'm now 62; I have worked with women ranging in age from my age, and above, down to mid-twenties and I don't think I have ever referred to any of them as a girl.

Anyway, apart from that, well done to both of you. I wish I could say that I was able to similarly encourage junior team members to take an interest in reading the code.

> How old were you and how old was she? And where in the world was this? For comparison I'm a British man who has lived in Norway for the last 32 years and I'm now 62; I have worked with women ranging in age from my age, and above, down to mid-twenties and I don't think I have ever referred to any of them as a girl.

This is probably a cultural thing: outside of the UK, I've often heard 'girl' used as the female equivalent of 'guy'.

As the sibling comment says, it's nothing special over here. Also, she is a really tiny person, and it's one of our funny things to call her a tiny kiddie girl who's always cold :) I'm the old grumpy techie uncle.
Besides code reviewing, it is useful to spend some time just to read and study commits made by other developers to observe and learn how they do things.
There are folks who are junior in their attitude and experience, but not in their coding or design skill set. I’m very senior, yet I’d say I suck at reviewing code. There are other things I’m good at, code reviews just aren’t one of those things. My best code reviewer on the team is a dude who’s just out of school. In fact, he’s probably the second best reviewer I’ve seen in 20 years in this industry, and the other dude is only better than him because he had incredibly deep knowledge of a gnarly problem domain specific to that particular team. Frankly, I’m shocked that someone who’s 22 years old can be this good, and I no longer believe there’s that huge of a gap in technical skill between junior and senior folks per se. I also think that people of such extreme skill should be paid at the same rate as the senior people even though they do not possess an illustrious resume quite yet. It pains me to see that he could be easily making three times as much if he only had “worked on such and such bullshit products for 10 years” on his resume. If I ever poach him, I’ll make sure he gets paid really well.

The main point is, just because someone is nominally “junior” means little to nothing in terms of their ability to write and review code. The advantage of experience is largely in knowing how to restrict the search space when solving any given problem.

This is a sensible topic. People label junior/senior based on experience (or time) when they should be labeling based on skillset. I've seen seniors that cannot even write a reasonable complex sql query and juniors that rock whatever project they are put on. From this example, I can clearly see which one is more valueble.
A recurring theme I've seen is senior dev's not asking other devs for feedback. While it's obviously something that would be great for the junior dev, usually senior devs tend to prefer to be the reviewer, not the reviewee. But I think this is to their folly; and certainly inhibits any juniors on the team.