[zeteo]

>I've been in this business for over 25 years [...] The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear. [...] Most code out there is shit code. Denying it is not going to help either.

I'm sorry, I respect your experience but this post is completely uninformative. It's much more specific on how awesome you are than on how to distinguish between "shit code written by shit coders" and "less than optimal code written by good coders"; not to mention dealing with and improving either.

It's possible to spend a long time in an industry and accumulate much unfounded prejudice along with solid knowledge. As long as the appreciation of "shit code" and "shit coders" remains subjective, it's virtually certain you'll also be considered one someday, when the prevailing paradigms and fashions change again.

[consultant23522]

As a coder the best compliment I've ever gotten was from a consultant. It was basically something like, "Hey, you're the [my initials] that wrote a big chunk of [system]? I can really tell the parts you wrote from the rest, it's so much easier to follow and understand." I had written the original code for that project solo and then it was passed on to another team for maintenance. That, to me, is the best thing a fellow coder can say, that my code was easy for them to maintain.

Conversely, I've seen code written in Java where instead of using objects the original coders used hashmaps with key/value pairs for fields. Sometimes they used some public static strings or an enumeration for the keys but often times they're just randomly hard coded throughout the program with string literals for field keys.

In another system I've worked on the coders did not understand objects/collections at all. So rather than having an array of type Person you had the Persons object that looked like this:

Persons { String[] first_name; String[] last_name; String[] address; }

While it's true that good vs bad code is somewhat subjective... code like the examples I provided above is pretty horrible by the standards of all but the worst coders.

[gruseom]

Persons { String[] first_name; String[] last_name; String[] address; }

Are you sure they didn't do it for performance? That is a well-known pattern for getting better data locality ("structure of arrays" vs. "array of structures").

[RogerL]

I was thinking the same thing; in such a case a // coded this way for cache coherence goes a long way.

[solistice]

I think it's a bad case of "dislike due to knowledge".

It's stark in the arts, but it applies to almost every human endeavor. As an example in the arts, I dance, and I'm good at it according to almost everyone who sees me dance. But I see myself as a terrible dancer. If I make a video of me dancing, others see every part that's well executed. I'm accustomed to them, and I tend to ignore those parts in favor of every part that's sloppy, every part that just doesn't look right.

And it's no different for code. You know what one of the marks for good code is? If the guy writing it is tearing it apart in the comments. Where do you see /* This is a dirty hack I'm ashamed of */? Usually right next to stuff that's a stroke of genius, or at the very least really good code.

It's strange that the more you know about something, the less comfortable you get with your knowledge, but it seems almost universal that "Ignorance is bliss", or rather the corollary "The more you know, the less you think you know".

[Djehngo]

I do like code which has comments which describe the level of confidence the author has in some sections (I feel a happier refactoring code which is marked as being suboptimal).

But in my experience those comments are usually found above cases where it's possible to make a fix in one line rather than one hundred. (sleeping a thread for 0ms rather than re-architecting a gigantic callback structure).

[romaniv]

If I can open a project and refactor some piece of code to be 1/10th of it's former size, while making it both more readable and more efficient without changing what it does than it's shit. In such cases I honestly don't care how good the original coder was supposed to be or what excuses he has. And yes, if I write code that can be optimized that way, I will be the first to admit that it's shit.

[sanderjd]

It's easier to refactor something that has already been created than to create that thing. This is why refactoring is such a good thing. It doesn't mean the original creation was "shit", it just means that it was massively improved by refactoring, which is sort of the point.

[mgonzo]

That's like saying, hey that rough draft of my essay is just fine to use. Not it's not, it's a rough draft, clean it up (refactor your code).

[sanderjd]

That's not a very good analogy, and doesn't really address the point I was making. Note that my comment was very favorable to refactoring.

[adamconroy]

It is amazing how many software developers think they are awesome. And then of course think everyone else is shit.

Unfortunately that pretty much means everyone is shit relative to someone else.

So its important to remember, you are shit too.

[twistedpair]

Let's admit that while there is code that could be cleaned up and made more efficient, which isn't "shit," there remains code that is riddled with antipatterns, latent bugs, is undocumented, untested and otherwise ostensibly terrible. This is what should fall under the "shit" category.