4 ms·

> What if he's a fresh college grad or a junior developer? Even when I was in college, I didn't write crap. Obviously my code wasn't great, but it wasn't crap.

by maratd 11y ago

> What if he's a fresh college grad or a junior developer? Even when I was in college, I didn't write crap. Obviously my code wasn't great, but it wasn't crap. And there is a lot of crap out there, I see it every day. Based on the OP's description, we're talking about someone who isn't capable of producing quality work. You can either write code or you can't and it is very obvious by seeing the code. If the person can write code, but needs a few pointers, that's what code reviews are for. If they can't write code, they need to move on to a different profession ... or move up to management.

DigitalJack 11y ago
That's BS. Coding isn't some kind of magical incantation, in spite of the jokes in SICP. Anyone that can understand basic algebra can learn to code.
- woah 11y ago
  At some point, there needs to be some sense of "if you're not going to do it right, don't do it at all". Anybody could give a haircut, but do you want a bad haircut from someone who does not want to improve?
MaulingMonkey 11y ago
> Based on the OP's description, we're talking about someone who isn't capable of producing quality work. Ehh - I've seen coders who can produce quality work, but sometimes choose not to because of (perceived) time pressure or (perceived) lack of value. Their mental model for code generation is to generate crap, then identify the patterns, then refactor until it's not crap - where the last two steps are "optional". Time pressure: A new hire likely feels some pressure to prove they can be productive. Value: New grads may not be in the habit of maintaining code (having written lots of throwaway assignments), not so new programmers may be used to writing throwaway prototypes, or "code ownership" situations where readability by coworkers isn't valued. Heck, it's quite possible they realize their current code is crap, and may even plan to clean it up in a subsequent changelist. I do similar on solo projects & private branches for the sake of keeping 1 changelist ~ 1 change parity, as it makes it easier to figure out refactoring mistakes. That said, those changes should generally be either done before the code review request, or noted as intended followup - and some pushback is warranted.

by maratd 11y ago

DigitalJack 11y ago

That's BS. Coding isn't some kind of magical incantation, in spite of the jokes in SICP. Anyone that can understand basic algebra can learn to code.

woah 11y ago
At some point, there needs to be some sense of "if you're not going to do it right, don't do it at all". Anybody could give a haircut, but do you want a bad haircut from someone who does not want to improve?

MaulingMonkey 11y ago

> Based on the OP's description, we're talking about someone who isn't capable of producing quality work. Ehh - I've seen coders who can produce quality work, but sometimes choose not to because of (perceived) time pressure or (perceived) lack of value. Their mental model for code generation is to generate crap, then identify the patterns, then refactor until it's not crap - where the last two steps are "optional". Time pressure: A new hire likely feels some pressure to prove they can be productive. Value: New grads may not be in the habit of maintaining code (having written lots of throwaway assignments), not so new programmers may be used to writing throwaway prototypes, or "code ownership" situations where readability by coworkers isn't valued. Heck, it's quite possible they realize their current code is crap, and may even plan to clean it up in a subsequent changelist. I do similar on solo projects & private branches for the sake of keeping 1 changelist ~ 1 change parity, as it makes it easier to figure out refactoring mistakes. That said, those changes should generally be either done before the code review request, or noted as intended followup - and some pushback is warranted.