Earlier quoted context omitted.
That’s hilarious, what did the senior engineer say?
DRY
feedback is contextual.
Ask HN: I'm tired of intense code review cycles
21–30 of 55 posts
Re: Ask HN: I'm tired of intense code review cycles
#22I had a Lead like this. It go to the point where I would spend a significant portion of my working time in existential dread about submitting a PR because I knew they would just rip it to pieces. The worst part was small styling issues that would have been picked up by any linter - but the lead refused any requests for the team to use linting because “we have never used it and everything works fine” I lasted 4 months…
Agreed styling code comments are asinine. Teams need a common linter to leave it to the CI to determine the style, whatever it may be. It’s a waste of everyone’s time.
Re: Ask HN: I'm tired of intense code review cycles
#23It's a case of the perfect being the enemy of the good.
Is it possible that there's not too much work to do? In my experience, this happens when the reviewer has too much time on their hands. Parkinson's law comes to mind.
Re: Ask HN: I'm tired of intense code review cycles
#24My unpopular opinion is that code reviews tend to provide negative net value. They take a lot of time, rarely catch structural problems, and lower morale. For this, you generally get consistent braces and spaces, and you might catch some detail that would raise obvious alarms in your pre-prod environment.
Re: Ask HN: I'm tired of intense code review cycles
#25My suggestion is try and get feedback earlier. Whiteboard with your coworkers and architect what you are building once you have a pretty good grasp on how you want to solve a task. You probably have some code at this stage to feel pretty confident that it will work. Agree on naming of concepts and design at this point, allowing you to change direction without reworking too much. Of course further changes to design wi…
Indeed, it might be time to move on. Or at least talk to the reviewer that bothers me. Although I push for a lot of upfront agreement, most of the back and forth arises from little things, like a variable name being too long, a newline between struct members, or a docstring that could be removed because the code is expressive enough. I'm usually okay with all of these suggestions. Still, lately, I'm fell in a positio…
> Although I push for a lot of upfront agreement, most of the back and forth arises from little things, like a variable name being too long, a newline between struct members, or a docstring that could be removed because the code is expressive enough.
This pedantry is a cancer. If your PR comment starts with "Nit:" just shut up and go do something useful.
Re: Ask HN: I'm tired of intense code review cycles
#26> But now that the learning curve is flattening, I feel the weight of not having enough creative freedom to write something up quickly or try different designs
This sounds like the real problem, more than anything.
Perhaps it's a sign that the code reviews have done their job, and you've been trained well enough to become a code reviewer yourself.
It might benefit you to start asking for more authority to be discussing these new design ideas with whoever is in charge, and see what they have to say.
If you really think you know well enough to architect things on your own or improve architectural decisions, you should assert that belief and ask for opportunities to test it.
Re: Ask HN: I'm tired of intense code review cycles
#27You haven't mentioned anything about disliking code reviews other than the way this architect conducts them. It sounds more like you're tired of micromanagement than code reviews.
Re: Ask HN: I'm tired of intense code review cycles
#28I had a similar experience when I joined a team. The architect was highly opinionated and wanted things to be done in certain way.
The problem however wasn't with him.
The management would usually pin all technical debt and issues on this architect. He was supposed to be answerable for anything that goes wrong.
Which made him a control freak. He wanted to know anything and everything in detail.
It's more of a culture problem.
When I realized this, I started sympathizing a bit with him. Made sure he understood what I was trying to achieve and comfortable with the code base. He was reluctant to accept new ideas but I pitched them anyway.
This is the nature of the job I realized. And it brought peace to me. I did however consider new opportunities with more freedom. But the controlling nature of the team did not bother me
Re: Ask HN: I'm tired of intense code review cycles
#29It’s honestly a win-win. You’re getting paid to get better. It’s on their dime and not yours. The inverse of the situation is that you’re expected to churn out shitty code and it’s never fast enough. Thing break constantly and you never learn how to craft quality code. I’m in the same boat where I’m expecting the PR process to be rigorous. And at the end of the day I can tell the difference between the correct and elegant solution and what’s halved assed but gets it done. At the end of the day I want to be a craftsman where the art of the craft is clean correct software solution. You’re lucky to be in a position where code quality trumps all.
Re: Ask HN: I'm tired of intense code review cycles
#30I think it helps if a team considers everything to be temporary, and code reviews are more for understanding how things work, with some some captured discussion of how it could be re-done. The author should merge, declare victory, and move on, while someone else re-writes it to their liking. It shouldn’t be considered done until it’s been re-done twice by separate authors.
One thing I’ve realized about software “engineering” is that it’s layered thick with opinions. If you force your opinions on someone, they check out and you get nothing of value from them. It’s probably better just to let them do things their way, and find the place where they can add the most. Some architects think their job is to walk around the beach kicking sand castles.