[apaitch]

I'm not sure I can fully agree with the idea that programmers are self-taught in the sense of writing good code. I'm a student at the University of Waterloo, and in the courses in 1st and 2nd year a sizeable chunk of the marks depends on readability/documentation and such. We have coding guidelines and we lose marks for not following them. Needless to say, this doesn't mean most students at Waterloo write good, well-documented, readable code. Most of them are focused on getting the program to work, sprinkling in obvious comments (i.e. "//setting width to 60" ) and debugging when the tests fail. When they get marks off for poor documentation/readability they either complain or brush it off, claiming that since their program worked the rest isn't a big deal.

Bottom line: in my experience, the reason most programmers are self-taught with regard to writing good code is not that no one tries to teach them. It's that most of them don't think they NEED to know (i.e. don't place enough importance on it) and are willing to lose marks for it until they get to a job and they have no to choice but to, you guessed it, teach themselves. There are people who try to make the best out of their education, and these can be very good coders who learned by making the best of their education.

(Note: obviously this is a generalization - there are plenty of students who try to write good code.)

[lukev]

No personal reflection, but what "good code" means in a professional context is quite a bit removed from student assignments.

There are just some things you'll never learn, for example, until you have to interact daily with code you wrote a year ago.

[evilduck]

Student assignments also rarely operate in the sheer magnitude of real world programs.

In university, I think the longest assignment I had was in the ballpark of a couple thousand lines of code and you could pretty readily keep it all your head as you solved the problem, there's not too much abstraction or delegation of responsibilities, no interfacing with 3rd parties, few library dependencies, it's all written in a single language, etc, etc. And you wrote it all from scratch by yourself or in a small team with (likely) equally inexperienced peers, so you know all the clever tricks that were employed.

On the job, I deal with company's code base that's over a million lines of code and uses a very messy database, maintained by dozens of people or varying skill levels over the last decade, wrought from an unholy amalgamation of 3 different programming languages spread over several servers and reliant on a half dozen "support utilities" to keep applying band-aids to bugs that "aren't cost effective to fix".

Writing good code the interacts with bad code is one of my hardest professional endeavors.

[onemoreact]

Few of the good programmers I know write much in the way of comments. 1 good comment per 30-50 lines of code is actually plenty as long as the code is readable. (Edit: Plus one comment per WTF.) The problem is writing readable code is difficult and must be maintained.

PS: At best a comment only says what someone thinks the code does. Program for long enough and you will get bitten by this.

[lukev]

Furthermore, on a team of any size, it is virtually guaranteed that someone will change the code without changing the comment as well. Then you have a bunch of comments that are not only useless, but actively misleading.

[mindcruzer]

Hello fellow Waterloo student!