The startup one is eerily familiar. I sometimes think the most frequent comment I write is along the lines of "TODO: Should really write a better version of this, but it works for now..."<p>I've even started writing those comments before I've written the function :(
The Enterprise code brings back awful memories of working with a framework architected by someone who had obviously read the Design Patterns book and had the take-away of "Use these as often as they can be wedged in to have a better system."<p>God forbid I needed to add a single boolean field to a single screen. By the time I submitted the DB change request, then changed the abstract factory interface, then the abstract factory class, then the factory interface that generated, then the factory class, then the abstract DAO interface that generated, then the abstract DAO class, then the parent DAO interface, then the parent DAO class... <i>pauses to catch breath</i> ...then the child DAO interface, then the child DAO class, then the controller object interface, then the controller class, then the actual page, then the unit test, it was 4AM and time to go to sleep.<p>Let this be a cautionary tale to any future architects out there.. remember that flexibility is a MEANS, with the ends being less time and money spent coding and maintaining code. It's not an ends to itself, and can even be a hindrance to the ends.
In a similar fashion, "The Evolution of a Haskell Programmer" (I'm sure there are for other langs also)
<a href="http://www.willamette.edu/~fruehr/haskell/evolution.html" rel="nofollow">http://www.willamette.edu/~fruehr/haskell/evolution.html</a> :)
The Large Company version is way too small. It should have at least 20 code files and is provided to other departments as a hosted service that no one has access to due to security restrictions, and the only documentation for how to use it is a powerpoint that is 3 years out of date.
Don't forget the tests of each. The startup's tests are all commented out because they failed at some point or another, the large company's tests are five times as long as the actual code they test, and all other categories consist of the stubs provided by the IDE.
I've been watching my son go through MIT 6.00.1x. He's working on the first midterm this very minute.<p>One of the things I've noticed is that, yes, code quality is from OK to horrid sometimes. Rather than stand behind him and correct every little detail I've let him navigate the problem sets and quizzes mostly on his own. When he gets stuck I give him a shove in the right direction and see what happens.<p>I've reflected on this as I've never really looked at student code. By the time I was a college student taking my first programming course I had already built a number of microprocessor boards, learned how to program them in machine language and moved on to Forth and C. I think my code was reasonably clean by that stage. Still, I know it wasn't professional grade by any measure.<p>It's easy to forget where we all started from and, as a result, criticize student code as naive. Well, in most cases, it is. That's a fact.<p>What I have now realized from watching my son learn to code as well as interacting with him through the process is that he is not learning to code. He is learning to think. He is learning about dissecting problems into small conceptual units that he can then translate into code. Sure, he is learning python in the process. However, the problem solving, solution structuring and problem representation skills that are very much necessary to be a good software developer are mostly language agnostic.<p>Realizing this, the fact that he is writing code that isn't the cleanest or the slickest possible solution to a problem stopped bothering me. I want him to learn how to think first.<p>Not to say that I've completely ignored the issue. I let him finish the assignments on his own and then we sit down and do a code review session where I point out where and how things could be better. We've had cases of a dozen lines of code replaced by just a couple. And that's OK. That's how he is going to learn.
and the cat writes the most correct code according to most programming best practices - except for giving meaningful names to constants, variables and functions
The startup code is the cs101 code with two additional cases handled (and minus the contrived x==2 state), and a lot of documented thought about what could be done to improve.