>be 5x engineer on team of a bunch of 0.5x engineers >i'm the architect for a new project >spend a few days with the initial commits >writing one internal library from scratch, and modifying an existing open source library to suit our needs >+2000-400 lines of code in initial commits >"""coworkers""" have been given the overview and architecture diagram, but they still don't know what's really going on because they didn't write it with me (their choice, I offered to pair program) >pull requests sit untouched for a week >after a week of waiting, review is finally in >"can you rename this parameter to [insert something worse]?" >"can you change this indentation?" (even though the IDE did the auto indent based on style rules) >"can you use an enum here instead of an int?" (despite enums being considered bad practice on the platform) >and other superficial shit that doesn't change any of the core functionality or APIs
I wasted yet another week waiting around for fucking nothing. I would be light years ahead of where I am now if I didn't have to wait for these brainless clowns.
Has ANYONE actually had a positive experience with code reviews? I'm a senior dev. I firmly believe that review shouldn't be necessary for anyone above mid level. Code review has unilaterally been a massive waste of time on every team I've ever been on.
>I don't get to continue working >Coworkers have to stop working to review my code >I've written so much by the time they get to it that they can ONLY make superficial style nitpicks. They don't understand anything that I'm doing from a feature or architecture standpoint, so they have to go after whitespace in a build file
Every time.
Pull requests were a mistake. Keeping master pure is a mistake. Every team should do pair programming + extreme programming + tagged releases.
Change my mind. I work 10x faster alone and quality is the same.
if you have software where someone can siphon money out if they can get in malicious code you definitely need code review. For other cases meh. if everyone was at least 2x engineer its useful to learn from each other maybe.
Jack Morris
>if everyone was at least 2x engineer its useful to learn from each other maybe.
I agree, but this is covered by pair programming.
My last job was miserable because of no work-life balance. However, my day to day was pair programming with a brilliant 50x engineer (seriously -- we had 60 guys and he was responsible for at least half of the massive codebase). We didn't do reviews because we watched over each other as we wrote the code. We weren't confused by any of our code because we wrote shit together. Neither of us ever had to wait for ridiculous reviews. God I miss that shit.
This is the problem, right here. "Code review" doesn't work when you get a lot of code. If you're trying to review that, the only useful thing would be to have a meeting with the reviewers to walk through what's been programmed, the feature and the tests. The meeting should have them asking about things that might not have been tested, but mostly the meeting should be about them learning how to maintain, or possibly add features to what you've written.
The real problem is probably that you have a total shit management team. If they want code review, they should create and assign stories that can be done quickly, are well planned out, structured so they can be merged safely together with what's in production, and have feature flagging that would let you put stuff into master that's not ready yet so that the features wouldn't result in big PRs - but I'm willing to bet that every time this has happened to you, you had a "product manager" in charge of the feature who's never programmed in their lives.
Matthew Nguyen
>2000-400 lines of code
I opened the pull requests around +600-100 but kept pushing commits daily until it grew to that. I was still working on the same feature.
This is what always happens
>Open PR with a reasonable amount of code >Wait for hours >Get frustrated and keep working >By the time the idiots look at it, it's too much for their peanut brains to comprehend >"hurpa durp can you change this capitalization? merge is blocked until you do :>)"
Evan Morgan
Demand pair programming. It's the quick solution.
Jacob Bell
I'm not in a position to demand. I'm the architect of this particular project, but I'm not the most senior person on the team.
There's a staffy (one of the peanut brains, only promoted due to years served) and a manager above me. They both demand code review. Oh, and according to them, this is the only way to write software. Every other way is wrong.
Nathaniel Wright
Those white claw selzter are pretty good. No added sugar just a fizzy drink with hint of berry.
Levi Anderson
they don't taste like they have any alcohol. pretty remarkable desu
Evan Morgan
Programming productivity inversely proportional to the number of programmers involved, that's well known.
