[skohan]

Probably I am being a bit hyperbolic. I could be more precise and say: code quality is a solution you should reach for if and only if you are running into real maintainability problems.

But I strongly disagree with the sentiment that someone should not write code in a certain language, or should not contribute to a project until they know how to write idiomatically according to all the "accepted" best practices. It's a pedantic and elitist attitude which has little to do with making good software, and runs counter to the practice of learning how to use a language, which is necessarily a process involving ignorance, trial and error.

[nocman]

I think somewhere in the middle is a good place to start. This can be managed by limiting the scope of code a "language newbie" writes (until they get reasonably up-to-speed) -- if/when that is possible. It also helps if you have someone experienced in the language who can help point them in the right direction when they need help. That can be a challenging thing to do well. Deciding where to provide direction, and where to just let them figure stuff out on their own can be difficult. You can come off as being too picky, or just being a jerk when you were just sincerely trying to help. I think to do it well you have to be vigilant about keeping your own ego in check. It has been my experience that most people who are fairly good at something (present company included) can slip into the state of "thinking more highly of themselves than they should". That's always counter-productive, and in my experience good "mentors" (or whatever you want to call them) are the one's who excel at avoiding it.

[lupire]

By the time you have real maintainability problems, it's too late to improve code quality.

[skohan]

It's never too late. I've had to pick up development on orphan projects before, and some of them are real stinkers. You can always quarantine the bad bits and start to impose a proper separation of concerns.