Hacker News new | past | comments | ask | show | jobs | submit login

This sounds like some non-engineer talk that ends up fucking the team up 1 year later as there code starts breaking everywhere, the code becomes very difficult to refactor, new hires start to struggle ramping up, etc.

I agree that sometimes people can be too focused on perfection in code reviews but consistency, modularity, and other seemingly unimportant things are crucial in maintaining hygiene for your project




> This sounds like some non-engineer talk

Does it merely sound like non-engineer talk, or is it actually non-engineer talk? I just want to make sure you aren't making the wrong assumption or implying the wrong thing. I've been saying what I've been saying as a result of my 5+ years experience doing full-time software engineering.

> I agree that sometimes people can be too focused on perfection in code reviews but consistency, modularity, and other seemingly unimportant things are crucial in maintaining hygiene for your project

It's interesting to me how easily people here are assuming that I'm implying the absence of standards merely because I'm suggesting people opt not to chase perfection in favor of providing a non-blocking pathway for engineers to make changes or improvements. Maybe my phrasing is poor.

I don't think you and I disagree that consistency, modularity, etc., are important and should have some amount of enforcement. The point I'm trying to make is that, in my experience, people sometimes go too far with this, so there should be some set expectations as to the limits of an individual code review. Limiting the amount of review iterations in a unit of work and splitting feedback-related work into other tickets can help address the issue of perfection zealotry.


What I meant is, I've heard this kind of language from non-engineers before (mostly PMs) trying to get developers to ship something in a bad state. Most probably because they'll be gone before they start having to deal with the repercussions of the technical debt.

>Limiting the amount of review iterations in a unit of work

Fully agree. I think there should only be two iterations max, preferably just one.

>splitting feedback-related work into other tickets

Would never work at places I've worked. The backlog of "important tasks" is never-ending so code cleanups, optimizations, etc. never get done because there is always higher priority work. This isn't really in control of the team because even if the PM agrees to let you lose a week of productivity making the code better without adding features there's a good chance their manager, the engineering director, etc. won't like to see that. So at least in my experience you only have one shot at getting that code in a good state, with the alternative being the code slowly getting worse and worse until it gets so bad you opt for a rewrite or lengthy refactor


That's a totally valid point, and perhaps I am too optimistic. I do think that a company with the right values could do that properly, but most don't, including best ones I have worked for.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: