Pedantic is the wrong approach to technical debt though. Almost every aspect of technical debt is about trade-offs.
If what you're doing appears pedantic it should come accompanied by an explanation of why the trade off the developer took is not ideal.
>I also ask a lot of pretty dumb questions during a review because I want to make sure that my understanding of the requirements matches the understanding the other engineer had.
Your code should really come accompanied by tests which you can read and use to understand what the precise interpretation of those requirements was.
That is not objective fact across projects. That means either the process or culture is bad.
Obviously, we do weight how much time it takes to fix it vs how much of the debt it actually is. We would not had that much independence in these decisions if we did not.
You get told to quickly write something as a Proof of Concept. Then get told, it works so put it in the code and reelase it. We will rewrite it later.
You never get to rewrite it later.
Over time the code base goes to hell. Every single time
The really big mess tend to be emergent - when features and code base grew too much for original architecture over time. You cant prevent that one by detailed code review and it takes a lot of effort to fix it.
But then we had 5% unit test coverage on a 5million+ LOC code base, they were terrified that refactoring (with no tests to back it up) might break things.
We were writing medical software and they were very risk adverse (obviously), so if i refactored a method I would have to raise that and would mean test cases would have to be written and manually run to ensure I hadn't broken anything.
So refactoring hardly happened (The code was an absolute mess), when i left they were working on a project to fix it but the timescales for it were 5 to 10 years.