Ever make a comment regarding the performance of applications written for the .NET platform, or about Java’s performance and/or, God forbid, the current system requirements of most large-scale J2EE implementations, only to have some dumbass jump on you about how your comment is just the typical knee-jerk, “C/C++ elitist” reaction to the word “Java” (or “C#”, or whatever), never stopping to think that you might actually have an informed opinion about it based on actual experience?

And funny how they never consider their reaction to be a knee-jerk reaction to your comment?

Dumbasses…

$0.02 to buy a clue: Remember “HotSpot”? Do you think it was created because Java was already fast enough, or because there was an actual performance problem it was supposed to address? Think about it…

One of the things I have noticed is that the ideals of design are often misused or misapplied.  More often than not (in my experience), this happens more often with developers that have more academic experience than real-world experience.

Nothing is worse than a recent CS graduate with a masters degree that has less than 2 years real-world experience creating a 23-page detailed design document for something as simple as a word-counting application.

Schools may teach software design, but they may fail to teach when it is best to forgo the design and start coding, letting let the design evolve naturally from the code, and not the other way around.

When designing first, inexperienced developers are more likely to over-engineer a solution.  They may see entire objects with rich hierarchies where a simple basic-type variable would work fine.  Only with experience does one realize to spot the situations where spending too much time on design is detrimental to a software project.

When I was younger, I learned: Think First, Code Later.  However, wisdom is what caused me to realize that thinking before coding is not necessarily the same as designing before coding.