The lone software developer is the reason for most bad software and most spaghetti code. A lone developer will sit down and code before making a plan. Since there is nothing to explain to anyone else, there is absolutely no reason to make a plan or to write any documentation. There is no reason to comment code.
Any software developer who has worked in a development team knows just how the team dynamic changes compared to an individual coder. In a team, all your code must be justifiable. Any areas of ambiguity, inefficiency, or prone to error will be caught by other developers. Any code comments are written with other developers in mind (instead of simply “Notes to Self”).
A good software team needs a leader. Software development is very personal work. A developer sits down and wrestles with code from morning until night. Even when in a team, he is often alone with functionality or bugs and must do what is necessary to complete them.  Any criticism of this work at the end of the day is a recipe for disaster. A team leader, with a position of authority (but preferably with a good dollop of tact) needs to be able to step in and clean up the areas ambiguity at the earliest moment (daily, preferably).
Iâve worked in environments where all greenfield projects are given to a Grad student to cut their teeth on before working on the big applications. Frequently, these small project become critical systems. When things go wrong, the code is given to more senior developers to fix. So, senior developers make patch work fixes on systems which began on a shaky foundation already.
But the truth is, not every project is big enough for an entire team. In those cases, peer review becomes even more important.