I know this implies that the reviewer didn’t care to read the bigger PR, but I think this might actually be legit. If your PR is only 10 lines long, then chances are those lines are very dense, or intricate in some other way. However, if you submit 500 lines, then it’s probably mostly boilerplate code with trivial adaptions.
No-one in their right mind would submit 500 lines of substantial code.
Has no one here ever worked on a new project or even a new feature in a decently sized codebase? Working exclusively in maintenance / minor change mode has to be exhausting.
Depends on what you classify as “minor change”. When I took up my first professional project, I found a plethora of little things to improve which would make users happy. That was very satisfying.
On the other hand, writing yet another module that displays a list of Foos, lets the user create a Foo, show the details of Foo, update it, and delete a Foo, becomes dull quickly, despite being a “new feature”.
You’d be surprised. Especially if the testing environment is not readily available or if automated tests are not functional and comprehensive, large code changes can be the norm. A developer may habitually hang onto their code until a big chunk is complete, at which point it will take heaps of debugging to uncover where the errors are. This is why we need IaC to quickly create testing environments that closely mirror prod, and trunk-based development to ensure code changes are small and issues are caught as early as possible.
I know this implies that the reviewer didn’t care to read the bigger PR, but I think this might actually be legit. If your PR is only 10 lines long, then chances are those lines are very dense, or intricate in some other way. However, if you submit 500 lines, then it’s probably mostly boilerplate code with trivial adaptions.
No-one in their right mind would submit 500 lines of substantial code.
Oh sweet summer child…
Has no one here ever worked on a new project or even a new feature in a decently sized codebase? Working exclusively in maintenance / minor change mode has to be exhausting.
Depends on what you classify as “minor change”. When I took up my first professional project, I found a plethora of little things to improve which would make users happy. That was very satisfying.
On the other hand, writing yet another module that displays a list of Foos, lets the user create a Foo, show the details of Foo, update it, and delete a Foo, becomes dull quickly, despite being a “new feature”.
You’d be surprised. Especially if the testing environment is not readily available or if automated tests are not functional and comprehensive, large code changes can be the norm. A developer may habitually hang onto their code until a big chunk is complete, at which point it will take heaps of debugging to uncover where the errors are. This is why we need IaC to quickly create testing environments that closely mirror prod, and trunk-based development to ensure code changes are small and issues are caught as early as possible.
500 line of substantial code happens once in a while in my team. Goes beyond that sometimes.
Saaaame, pretty frequently on my team actually