I ruin developers’ lives with my code reviews and I'm sorry
1–10 of 199 posts
Re: I ruin developers’ lives with my code reviews and I'm sorry
#2Congrats to the author for realizing that confidence doesn't equate skill. This isn't being a pink unicorn, it's simply humility.
The real danger of confusing the two is that real skill dulls if you let overconfidence take over, since the very thought of being "better than others" prevents you from accepting that maybe there are things that you don't know or haven't considered.
For example, is "destroying" a coworker's commit in a code review really really helping? Did the person perhaps forget to consider that hiring to refill the position of a fired developer actually costs physical money (as opposed to time spent on coaching?) or that perhaps a lot of time is being spent on nitpicks without bottom-line value or that tip-toeing around egomaniacs can stunt autonomy and therefore creativity? This is not merely a matter of whether you're lulling yourself into some false sense of superiority/duty/whatever; thinking in terms of bigger and bigger pictures is an actual skill that one needs to develop when going up the career ladder.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#3God he sound insufferable.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#4> And if you tell me that you haven’t had this feeling ever, then you’re lying. Tell me about higher goals, training rookies and all that — I know you’re simply too full of themselves. And if you try to tell me that you learned to defeat that feeling (however it manifests in you), then I must be a pink unicorn.
I think that this is called projection.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#5Congrats to the author for realizing that confidence doesn't equate skill. This isn't being a pink unicorn, it's simply humility. The real danger of confusing the two is that real skill dulls if you let overconfidence take over, since the very thought of being "better than others" prevents you from accepting that maybe there are things that you don't know or haven't considered. For example, is "destroying" a coworker…
If you have to "destroy" every PR from a developer, you're wasting more time (money) than it would take to replace them.
Why should be bad PRs ever be allowed for any reason?
Re: I ruin developers’ lives with my code reviews and I'm sorry
#6Congrats to the author for realizing that confidence doesn't equate skill. This isn't being a pink unicorn, it's simply humility. The real danger of confusing the two is that real skill dulls if you let overconfidence take over, since the very thought of being "better than others" prevents you from accepting that maybe there are things that you don't know or haven't considered. For example, is "destroying" a coworker…
If you have to "destroy" every PR from a developer, you're wasting more time (money) than it would take to replace them. Why should be bad PRs ever be allowed for any reason?
bad PRs shouldn't be allowed, but you don't have to be a smug a-hole while reviewing PRs.
hell, that's a GREAT opportunity to get this "bad developer" under your umbrella and start mentoring him to be a better developer.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#7Congrats to the author for realizing that confidence doesn't equate skill. This isn't being a pink unicorn, it's simply humility. The real danger of confusing the two is that real skill dulls if you let overconfidence take over, since the very thought of being "better than others" prevents you from accepting that maybe there are things that you don't know or haven't considered. For example, is "destroying" a coworker…
If you have to "destroy" every PR from a developer, you're wasting more time (money) than it would take to replace them. Why should be bad PRs ever be allowed for any reason?
> Why should be bad PRs ever be allowed for any reason?
Define bad PR. Are you sure that your definition of "bad" is accurate?
Re: I ruin developers’ lives with my code reviews and I'm sorry
#8I have been on several teams that found the following article "Unlearning toxic behaviours in a code review culture" very helpful:
https://medium.com/@sandya.sankarram/unlearning-toxic-behavi...
Re: I ruin developers’ lives with my code reviews and I'm sorry
#9Nothing makes working at a place more unbearable than having to deal with someone that gives an excessive amount of criticism on working code, at least that's how I feel. I've been in that situation before and it made me never want to submit pull requests. It made me even madder when other developers, whose code was no better than mine but had been at the company longer, received basically no critiques.
Some might say, oh it's hazing, well fuck you because I'm quitting. I'm not putting up with any amount of hazing at a job. If I have to spend 8 hours everyday somewhere I'm for sure not going to spend it with some asshole.
Re: I ruin developers’ lives with my code reviews and I'm sorry
#10Congrats to the author for realizing that confidence doesn't equate skill. This isn't being a pink unicorn, it's simply humility. The real danger of confusing the two is that real skill dulls if you let overconfidence take over, since the very thought of being "better than others" prevents you from accepting that maybe there are things that you don't know or haven't considered. For example, is "destroying" a coworker…
If you have to "destroy" every PR from a developer, you're wasting more time (money) than it would take to replace them. Why should be bad PRs ever be allowed for any reason?
There are many ways to solve any problem. If I reviewed every PR with the standard "is this exactly how I would have done it", I too would be destroying every PR I review. And I'm not even that good at coding - I'm the type of generalist who cares about things like the business beyond the code base.
What really matters is whether the code is solid and whether it will actually cause problems. Just because a PR isn't character-for-character how I'd write it doesn't mean it's bad. Based on the author's experience with the fired employee's replacement being just as bad, my guess is he was over defining goodness and raising the bar too high.
Bad PR to me means: bad runtime complexity, bad formatting, bad security, bad memory use, bad understandability. If it meets all those bars, which for a crud app is usually easy, then it should probably pass. I'll sometimes leave a "I would have done _x_ differently" comment on matters of taste _if I think it will help the other developer_.