To give some 'yes, that's maybe great, but is it practical?' feedback; I often work with (bigger) companies where code reviews fail if you don't have: - commen

To give some 'yes, that's maybe great, but is it practical?' feedback; I often work with (bigger) companies where code reviews fail if you don't have: - comments, the more the better - design patterns, the more the better Even if absolutely useless; the over-architecting just for over-architecting sake is quite... Not only does it take a lot of time to actually reuse the code (a lot/all of those patterns are conceived for reusing code in the first place but in reality it takes people a long time to get into them and the gains are not convincing aka I see people just plonking together a little microservice in a fraction of the time with Node and (virtually) no design patterns to replace (parts of) the java/c# monster that does the same thing just to make the deadline or to skip diving into the sea of blackness), but the comments really do not help at all; they are just there to have comments. And the design patterns (+ the way they are used) are considered standard (they are, but not for young people who have no degree and no experience applying them, or maybe even knowing they exist). Still, without all that, the merge requests are being declined until you pop in random drivel 'for best practice'. I am a fan of terse but readable code these days (it changes somewhat); the design patterns are more and time wasting (to me), especially when enforced in this way (but I think everyone will agree with that anyway).