Just to supplement great answers by Marc Claesen and cbeleites. In academia, when people write code, it is common that:

• Problems are often open-ended - so perhaps the data structure people start with will be used later for something else, for which it is suboptimal. Also, many things are not properly designed, because everything changes. Compare it to writing a typical commercial software, where things are specified from the beginning and usually far from cutting-edge (even if demanding, not "the first time").
• Maintainability is not a requirement - small piece of software, not used later, with no-one else going to take over the code (and it is way easier to understand one's own code than code by others - even if it is chaotic, you know what is where). Compare it with situation, where after the author leaves someone else is going to look after the code.
• People work alone or on legacy code - very opposite situations, but giving similar results. In the first case (as above), people can understand their chaotic code; in the second (e.g. modifying pieces in old Fortran code) - people have to adopt in making small, often - not anticipated, changes, adopting to the existing code base.

Personally (coming from pure academic background), I've learnt most o good coding practices, when collaborating with others:

• by learning from others - some coding practices does not require a lot of brainpower, but a lot of experience - the wisdom telling that a given "smart solution" will become problematic to maintain in longer run (as most of kludges (= ugly hacks)),
• by collaborating - many times I realized that what was reasonably clear for me, was a totally unintelligible cthulhu fhtagn (yet powerful) for others (and the other way as well - a nice code for someone else was a challenging riddle for me),
• all in all, many good practices are in fact going to the least common denominator of skill (and not-smart people are already close it); clever code by one will be difficult for others.

And a dessert - the curse of the gifted, a comment to the last point:

You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself. As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals must develop in order to handle the kind of problem complexity you eat for breakfast.

(Source: http://lwn.net/2000/0824/a/esr-sharing.php3; or abbreviated: http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN)

And it was addressed by Eric S. Raymond to Linus Torvalds...

Just to supplement great answers by Marc Claesen and cbeleites. In academia, when people write code, it is common that:

• Problems are often open-ended - so perhaps the data structure people start with will be used later for something else, for which it is suboptimal. Also, many things are not properly designed, because everything changes. Compare it to writing a typical commercial software, where things are specified from the beginning and usually far from cutting-edge (even if demanding, not "the first time").
• Maintainability is not a requirement - a small piece of software, not used later, with no-one else going to take over the code (and it is way easier to understand one's own code than code by others - even if it is chaotic, you know what is where). Compare it with situation, where after the author leaves someone else is going to look after the code (or one need to constantly consider hiring one more developer to speed up the progress).
• People work alone or on legacy code - very opposite situations, but giving similar results. In the first case (as above), people can understand their chaotic code; in the second (e.g. modifying pieces in old Fortran code) - people have to adopt in making small, often - not unanticipated, changes, adopting to the existing code base.

Personally (coming from pure academic background), I've learnt most o good coding practices, when collaborating with others:

• by learning from others - some coding practices does not require a lot of brainpower, but a lot of experience - the wisdom telling that a given "smart solution" will become problematic to maintain in longer run (as most of kludges (= ugly hacks)),
• by collaborating - many times I realized that what was reasonably clear for me, was a totally unintelligible cthulhu fhtagn (yet powerful) for others (and the other way as well - a nice code for someone else was a challenging riddle for me),
• all in all, many good practices are in fact going to the least common denominator of skill (and not-smart people are already close it); clever code by one will be difficult for others.

And a dessert - the curse of the gifted, a comment to the last point:

You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself. As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals must develop in order to handle the kind of problem complexity you eat for breakfast.

(Source: http://lwn.net/2000/0824/a/esr-sharing.php3; or abbreviated: http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN)

And it was addressed by Eric S. Raymond to Linus Torvalds...

And as a side note (as programming is more and more prevalent), now scientists realize that good practices and workflows are important, see e.g. http://software-carpentry.org/.

Just to supplement great answers by Marc Claesen and cbeleites. In academia, when people write code, it is common that:

• Problems are often open-ended - so perhaps the data structure people start with will be used later for something else, for which it is suboptimal. Also, many things are not properly designed, because everything changes. Compare it to writing a typical commercial software, where things are specified from the beginning and usually far from cutting-edge (even if demanding, not "the first time").
• Maintainability is not a requirement - small piece of software, not used later, with no-one else going to take over the code (and it is way easier to understand one's own code than code by others - even if it is chaotic, you know what is where). Compare it with situation, where after the author leaves someone else is going to look after the code.
• People work alone or on legacy code - very opposite situations, but giving similar results. In the first case (as above), people can understand their chaotic code; in the second (e.g. modifying pieces in old Fortran code) - people have to adopt in making small, often - not anticipated, changes, adopting to the existing code base.

Personally (coming from pure academic background), I've learnt most o good coding practices, when collaborating with others:

• by learning from others - some coding practices does not require a lot of brainpower, but a lot of experience - the wisdom telling that a given "smart solution" will become problematic to maintain in longer run (as most of kludges (= ugly hacks)),
• by collaborating - many times I realized that what was reasonably clear for me, was a totally unintelligible cthulhu fhtagn (yet powerful) for others (and the other way as well - a nice code for someone else was a challenging riddle for me),
• all in all, many good practices are in fact going to the least common denominator of skill (and not-smart people are already close it); clever code by one will be difficult for other.

And a dessert - the curse of the gifted, a comment to the last point:

You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself. As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals must develop in order to handle the kind of problem complexity you eat for breakfast.

(Source: http://lwn.net/2000/0824/a/esr-sharing.php3)

And it was addressed by Eric S. Raymond to Linus Torvalds...

Just to supplement great answers by Marc Claesen and cbeleites. In academia, when people write code, it is common that:

• Problems are often open-ended - so perhaps the data structure people start with will be used later for something else, for which it is suboptimal. Also, many things are not properly designed, because everything changes. Compare it to writing a typical commercial software, where things are specified from the beginning and usually far from cutting-edge (even if demanding, not "the first time").
• Maintainability is not a requirement - small piece of software, not used later, with no-one else going to take over the code (and it is way easier to understand one's own code than code by others - even if it is chaotic, you know what is where). Compare it with situation, where after the author leaves someone else is going to look after the code.
• People work alone or on legacy code - very opposite situations, but giving similar results. In the first case (as above), people can understand their chaotic code; in the second (e.g. modifying pieces in old Fortran code) - people have to adopt in making small, often - not anticipated, changes, adopting to the existing code base.

Personally (coming from pure academic background), I've learnt most o good coding practices, when collaborating with others:

• by learning from others - some coding practices does not require a lot of brainpower, but a lot of experience - the wisdom telling that a given "smart solution" will become problematic to maintain in longer run (as most of kludges (= ugly hacks)),
• by collaborating - many times I realized that what was reasonably clear for me, was a totally unintelligible cthulhu fhtagn (yet powerful) for others (and the other way as well - a nice code for someone else was a challenging riddle for me),
• all in all, many good practices are in fact going to the least common denominator of skill (and not-smart people are already close it); clever code by one will be difficult for others.

And a dessert - the curse of the gifted, a comment to the last point:

You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself. As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals must develop in order to handle the kind of problem complexity you eat for breakfast.

(Source: http://lwn.net/2000/0824/a/esr-sharing.php3; or abbreviated: http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN)

And it was addressed by Eric S. Raymond to Linus Torvalds...