Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Genius
You are right!
I tended to agree with the whole article until I read this:
No big deal if the code’s not good, I can fix it myself it I need to.
Please don't do that. Imagine being that junior developer: he tries his best, and a few days later he pulls a commit with all of his work gone and totally rewritten, how'd you feel? You're actually stating he's totally useless — without saying a single word. That's even worse than being slapped in a face with a ton of shit during code review.
I prefer pair programming/refactoring sessions. Well, yeah, first sessions might look like you're doing all the work and he just operates the IDE. But people learn much better when they are deeply involved. A few sessions more and, viola, your junior developer is becoming closer to a middle.
I agree with what symbix says above.
For the most part this article makes sense and is interesting. The conclusion of what to do about it in his particular case isn't the best solution though IMO. This idea of leaving a short review on code that has fundamental problems, and then rewriting it later on yourself, is not sustainable and not helpful to the junior developer. Now you have the problem of the developer not gaining any new insight into how the solution could be improved, and they'll continue to make those same mistakes in the future. Along with the practicality that you're going to have an increasingly unmaintainable codebase. I definitely wouldn't want that as the person submitting code that needs improvement personally.
The approach IMO should be to leave reviews that are constructive and help the developer understand the issues in their code, so they can continue to improve (or show you why their approach is a good one) and over time the reviews will be less problematic because the team is on the same page. The fact that in the first example that instead of this, the developer continued to have problems and was let go, tells me the reviews must have really not been very constructive at all.
The idea of not being mean spirited or tearing people down is a good thing to share and think about, but don't go too far in the other direction.
For the most part this article makes sense and is interesting. The conclusion of what to do about it in his particular case isn't the best solution though IMO. This idea of leaving a short review on code that has fundamental problems, and then rewriting it later on yourself, is not sustainable and not helpful to the junior developer. Now you have the problem of the developer not gaining any new insight into how the solution could be improved, and they'll continue to make those same mistakes in the future. Along with the practicality that you're going to have an increasingly unmaintainable codebase. I definitely wouldn't want that as the person submitting code that needs improvement personally.
The approach IMO should be to leave reviews that are constructive and help the developer understand the issues in their code, so they can continue to improve (or show you why their approach is a good one) and over time the reviews will be less problematic because the team is on the same page. The fact that in the first example that instead of this, the developer continued to have problems and was let go, tells me the reviews must have really not been very constructive at all.
The idea of not being mean spirited or tearing people down is a good thing to share and think about, but don't go too far in the other direction.
Great story with a happy ending. Thanks!
If there's a member of the team that's consistently struggling code reviews are a terrible way of learning. They need to be paired with various (not just one) developers. Any developers who get sniffy about supporting the team get reminded they are part of a team and toxic behaviour can't be tolerated. If a, subjectively to our team, bad coder remains bad and consistently costs clean up effort, then you haven't got a team, or they're being assigned jobs incorrectly.
Don't ignore them, or do faceless reviews, mentor them.
Don't ignore them, or do faceless reviews, mentor them.
That was a very good read and something I'll need to give good thought at, so kudos on that! I can also issue very heavyhanded criticism at other people's work sometimes — and sometimes I am aware of that, but other times I'm just on automatic pilot. This was a very welcome reminder not to be a jerk.
I also wanted to bring something to your attention:
A very solid psychological theory establishes that people's opinions are mostly an emotional process, not a rational one. This is the reason why you can spend lots of time arguing with people who lack the knowledge to support their points of view and can't seem to find obvious flaws in their own arguments. Here's the thing: when we're arguing, rationality doesn't really make us look for truth — it only looks for arguments which justify our position. If we lack the foundations to build proper arguments or our position is untenable, we'll just make up crap ones — and still we'll believe in them every step of the way. That's why arguing about most stuff, but particularly about politics and religion, is a painstaking process where there's often very little to be gain. We don't want to change our minds — we want to persuade others, but at the same time, we often reject the possibility that we ourselves are in the wrong.
If this is something you find interesting, I'll strongly suggest you read Jonathan Haidt's «The Righteous Mind: Why Good People are Divided by Politics and Religion». Otherwise, at least I hope that you found the above explanation useful.
I also wanted to bring something to your attention:
It reminded me of an experience I had. I used to be convinced that gays = bad. I didn’t think about it much: some long time ago my dad told me that, and I remembered. Once I was in a bar with a party of liberals, and this topic came up. I immediately announced my position on the issue, and they’re like “Phil, that’s messed up”. And we started to argue. I haven’t ever thought about the issue seriously and didn’t have any decent arguments, but I couldn’t stop arguing nonetheless. I had one goal — to win and save face. I still don’t know why.
A very solid psychological theory establishes that people's opinions are mostly an emotional process, not a rational one. This is the reason why you can spend lots of time arguing with people who lack the knowledge to support their points of view and can't seem to find obvious flaws in their own arguments. Here's the thing: when we're arguing, rationality doesn't really make us look for truth — it only looks for arguments which justify our position. If we lack the foundations to build proper arguments or our position is untenable, we'll just make up crap ones — and still we'll believe in them every step of the way. That's why arguing about most stuff, but particularly about politics and religion, is a painstaking process where there's often very little to be gain. We don't want to change our minds — we want to persuade others, but at the same time, we often reject the possibility that we ourselves are in the wrong.
If this is something you find interesting, I'll strongly suggest you read Jonathan Haidt's «The Righteous Mind: Why Good People are Divided by Politics and Religion». Otherwise, at least I hope that you found the above explanation useful.
Reddit link — old.reddit.com/r/programming/comments/arx96h/i_ruin_developers_lives_with_my_code_reviews_and
This article caused a huge discussion.
This article caused a huge discussion.
When I was learning software development, one of the most valuable sources of information for me were forums. I asked a question and got bullied in response...
In my experience this is was the de facto standard for so many usenet programming groups. I remember the Perl group being outright hostile to new programmers, and setting up the rules against them.
Stack Overflow was a breath of fresh air when it came out. I was happy to never return to usenet after that.
Nice article! I bet it took a lot to arrive there and to share that with the world. Say, would you consider swapping the gender-specific pronouns «he/him/his» referring to other developers with gender-neutral ones like «they/them/their»? e.g. «If a developer brings me their code»
Oh, funny… I've read: if the developer IS a dick, we call him HE )))
And language and culture come hand in hand, and anyway, if we write in English, let' use English rules.
And language and culture come hand in hand, and anyway, if we write in English, let' use English rules.
The point here is that using «he» when referring to an abstract hypothetical programmer kind of implies it's a man. That's lack of grammatical gender for you.
Of course, speaking about a particular person using «he» is totally fine (as long as they are fine with being called «he», but that's a different topic).
PS you don't have to check if they have a dick.
Of course, speaking about a particular person using «he» is totally fine (as long as they are fine with being called «he», but that's a different topic).
PS you don't have to check if they have a dick.
What is wrong with you! How can you mess up this sentence with bad spelling! If you can't write 100% to perfection, don't write at all! «I can fix it myself it I need to.» Criticizing is a lot easier then helping/teaching. «I can fix it myself if I need to.»
I hoped to see examples of wrong/rubbish code, and how it could be rewritten in the right way.
Without that I see a developer, who claims he is a best developer in the world, and he just cannot see other good solutions. I think it is good way to listen, why he done such code, to understand approaches applied by those guys.
Without that I see a developer, who claims he is a best developer in the world, and he just cannot see other good solutions. I think it is good way to listen, why he done such code, to understand approaches applied by those guys.
talking about code reviews...here is another article that is very explanatory for those interested in joining the world of web development blog.quero.com/become-web-developer
Nice article! I bet it took a lot to arrive there and to share that with the world. Say, would you consider swapping the gender-specific pronouns «he/him/his» referring to other developers with gender-neutral ones like «they/them/their»? e.g. «If a developer brings me their code» KEEP IT UP. GOD BLESS THIS ARTICLE.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
I ruin developers’ lives with my code reviews and I'm sorry