I think Jeff is exaggerating a bit with his phrasing, but I think there's an important point there: humility is always important, and it's the only way you ever improve. As soon as you start being really satisfied with your own work, you stop trying to improve it, and that's a dangerous point to be at. Most of the best programmers I know personally are all highly self-critical about their work.
I also think it's important for one's job satisfaction and enjoyment of life that you take pride in your work and can be proud of your accomplishments, and I think it's important to be able to juxtapose that level of satisfaction with a constant drive to improve (I actually blogged about that topic a couple of months ago http://guidewiredevelopment.wordpress.com/2009/05/07/it-can-...)
It's also far too easy to assume that everything written by everyone else is crap simply because it doesn't map to how you would solve the problem, and while some of it certainly is crap, it's important to be charitable in your analysis there. Becoming better means being open to learning from other people's ways of doing things, and being a good teammate means giving your coworkers the benefit of the doubt and assuming that if something doesn't make sense to you or seems ugly, perhaps it's because the problem is more complicated than you thought, or perhaps they had to inherit some ugly legacy code, or perhaps the problem domain just wasn't well understood at the time the code was first written.
I also think it's important for one's job satisfaction and enjoyment of life that you take pride in your work and can be proud of your accomplishments, and I think it's important to be able to juxtapose that level of satisfaction with a constant drive to improve (I actually blogged about that topic a couple of months ago http://guidewiredevelopment.wordpress.com/2009/05/07/it-can-...)
It's also far too easy to assume that everything written by everyone else is crap simply because it doesn't map to how you would solve the problem, and while some of it certainly is crap, it's important to be charitable in your analysis there. Becoming better means being open to learning from other people's ways of doing things, and being a good teammate means giving your coworkers the benefit of the doubt and assuming that if something doesn't make sense to you or seems ugly, perhaps it's because the problem is more complicated than you thought, or perhaps they had to inherit some ugly legacy code, or perhaps the problem domain just wasn't well understood at the time the code was first written.