Not git, Perforce, but I used to have a guy on my team that would do weeks of work without checking in. 1000s of lines in 10s of files.
I gave him shit for every code review, every time we had 1-on-1s, and while he was doing his tasks. Nothing got through to him.
So I just kept dragging him back on check-ins. I'd nitpick the shit out of every line (and normally I hated that.) His stuff would inevitably break the build or be full of bugs anyway (duh) so I never felt bad that I was holding back his career since he was never getting things done "on time."
If you can't/won't break your work down into smaller chunks you aren't a skilled programmer and/or don't have respect for the people you work with who have to review your shit.
No it is not. It depends on the codebase - if it is something relatively new, a proof of concept or something that is bound to change soon, there is no point in slowing the development down just because it is "too large to digest".
If you're just rubber-stamping in code reviews, why even have them in the first place in that case? They aren't exactly providing you with any mileage at that point.
Sure but who's got time for all that aggravation? Especially if it's not part of the codebase I have to work with personally. LGTM and let it be someone else's problem.
17 Comments
JohnnyCanuck@lemmy.ca · 42 pts · 1y
Not git, Perforce, but I used to have a guy on my team that would do weeks of work without checking in. 1000s of lines in 10s of files.
I gave him shit for every code review, every time we had 1-on-1s, and while he was doing his tasks. Nothing got through to him.
So I just kept dragging him back on check-ins. I'd nitpick the shit out of every line (and normally I hated that.) His stuff would inevitably break the build or be full of bugs anyway (duh) so I never felt bad that I was holding back his career since he was never getting things done "on time."
If you can't/won't break your work down into smaller chunks you aren't a skilled programmer and/or don't have respect for the people you work with who have to review your shit.
ignotum@lemmy.world · 33 pts · 1y
LeFrog@discuss.tchncs.de · 15 pts · 1y
Python: nice try Satan, but not today
xmunk@sh.itjust.works · 3 pts · 1y
Also, Python: Please rewrite your multi-line lambdas into tuples of logic statements that you pick the last one of.
Satan has a firm grip.
starshipwinepineapple@programming.dev · 32 pts · 1y
GreenKnight23@lemmy.world · 7 pts · 1y
GissaMittJobb@lemmy.ml · 16 pts · 1y
The correct response to any PR that is too large to digest is to reject it and ask the author to split it up.
verstra@programming.dev · 8 pts · 1y
No it is not. It depends on the codebase - if it is something relatively new, a proof of concept or something that is bound to change soon, there is no point in slowing the development down just because it is "too large to digest".
Endmaker@ani.social · 10 pts · 1y
Then saying that you have looked through and reviewed the code would be lying. And that is unprofessional.
DudeDudenson@lemmings.world · 5 pts · 1y
Is sitting down and understanding the code in the PR not an option?
Endmaker@ani.social · 5 pts · 1y
I'm not sure what you are getting at.
homesweethomeMrL@lemmy.world · 1 pts · 1y
Clearly they hate efficiencies.
GissaMittJobb@lemmy.ml · 5 pts · 1y
If you're just rubber-stamping in code reviews, why even have them in the first place in that case? They aren't exactly providing you with any mileage at that point.
gnutrino@programming.dev · -1 pts · 1y
Sure but who's got time for all that aggravation? Especially if it's not part of the codebase I have to work with personally. LGTM and let it be someone else's problem.
phorq@lemmy.ml · 7 pts · 1y
Statistically, at least half of changes are just indentation anyway
lemmeBe@sh.itjust.works · 3 pts · 1y
Maybe in your PR's. 😁
caseyweederman@lemmy.ca · 1 pts · 1y
Spaces! Tabs! Spaces! Tabs!
NigelFrobisher@aussie.zone · 3 pts · 1y
Or maybe use a better workflow where you’re not first finding issues after the work is already done?