Live data from Hacker News

The code culture problem

fraustollc.com

31–40 of 162 posts

Re: The code culture problem

#31
post #17

This is similar to the discussion around "legacy code", which in many ways is corporate speak for "shit code". In his book "Working Effectively with Legacy Code", Michael Feathers provides an interesting definition of legacy code. He defines legacy code as code that is not under test. The idea is that if code is under test then it is easier to improve/refactor. Maybe instead of saying that code is "shitty", we should…

Now the question is, who's smarter, some punk kid, or the guy who wrote some code that is still running, still doing its job, still making money for the firm, 20 or 30 years later?

Because that's what "legacy" code is, if it wasn't doing something vitally important, it could just be deleted. It's not shit, it's the family heirlooms!

Re: The code culture problem

#32

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

You're probably right, what do I know I've only been programming professionally for 3 years.

However, I find that it's more helpful to have a positive attitude when reading code I didn't write. "Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with".

I'm not denying that I found seriously bad code running in production. And I'm not denying that it's more common that I would've believed. But the moment I start treating every piece of foreign code as shit, I'll miss out on interesting insightful techniques.

The point of this article is a reminder that it's easy to get sucked in the "this is shit" culture.

Re: The code culture problem

#33

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

Most code out there is shit code. Denying it is not going to help either.

So you do it "right" then, I assume. What do you think the next guy is going to say about your code? Do you really think they're going to praise the excellent code quality? Or will they declare to all around that it all needs to be rewritten because it doesn't conform to the newest flavor of the month?

I absolutely and unequivocally agree with the author: People declare everything around them as shit to prop themselves up, and the explain their own inadequacies in advance. There is shit code, granted, but by some measure of shit all code is shit. A viewer can destroy code as over or under engineered, over or under built, over or under abstracted, over or under object-oriented, over or under functional, and on forever, and anyone who thinks there is an actual right way in any reasonably complex system is demonstrating profound naivety.

The one thing that I will disagree with in the submission is the notion that this is a new or increasing pattern. It isn't, and has been the norm for decades. This is what developers do, especially those who are weak at reading code: Declare it shit in advance and just write your own.

Re: The code culture problem

#34
post #7

A factor I think the article doesn't point out clearly enough is how the main attraction of dissing code is that it serves as an ego-defense mechanism. Understanding code is, almost without exception, challenging. It's much easier on our self image if we believe the code is to blame, rather than us. An unfortunate side effect is that this perceived badness of the code is then often used as an excuse to not really try…

A good assessment in my opinion.

As a junior coder earlier in my career I found exactly the situation described. A co-worker was always griping loudly about how bad the code and architectural decisions of certain people supposedly were - all except his own, of course.

At first I was too diffident to form an opinion and considered whether he might be right. When I gained more experience, and finally got a look at what he was ranting about, it seemed to me that this guy's targets were not so bad and that his own output was hardly more impressive.

Eventually I saw other examples of this pattern and realized something: those who bluster in this way tend to be middle-range developers who are trying to cover up their own insecurities - while those who are really superior tend to be quieter, more businesslike and basically getting things done, and well, while those described above are going on in their "BS" sessions.

I don't claim to qualify for the latter group to the degree I would like, but when I hear the denigration, I ask what are the specific problems and what do we propose to do about them. And I try to promote a positive atmosphere, and really learn the code rather than just looking for where to put more duct tape.

Re: The code culture problem

#35

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

I'm just going to ask the question...

What do you think makes your code good?

I bet the next guy that comes around in 15 years and reads your legacy code (Grats on having code actually runs for 15 years!) will think it's the worst piece of shit ever created and are sure to think you are one of the worst developers in the world.

Re: The code culture problem

#36
post #13

"Psychological projection was conceptualized by Sigmund Freud in the 1890s as a defense mechanism in which a person unconsciously rejects his or her own unacceptable attributes by ascribing them to objects or persons in the outside world." In other words, we think out own code is "shit" so instead of dealing with that, psychologically, we just attack others.

Actually when I say "code is shit" I usually just mean the code. Often times I find it's my code when I look back, it's still shit though.

[deleted]

Re: The code culture problem

#37

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

Shit is useless, destructive and smelly. Unrefined code by an unrefined developer often works, but not as well as it can and is usually difficult to work with. Big difference. Just like most of the stuff reddit calls "epic" or "mind blowing" is often simply 'neat', most of the code you call "shit" often simply 'could be better'. The tendency to call unrefined code "shit" intimidates new coders and disincentivizes people from contributing to community projects.

Re: The code culture problem

#38

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

If the majority of code is shit, then it's not really a very useful observation to make repeatedly. So I think this goes back to the author's point that this is really a cultural or attitude issue.

It's like the friend who complains about everything all the time: constantly complaining about traffic, about the weather, about how the city is losing its charm, about his job, about his classes, about his parents, about his car, about his apartment, about politics, about how stupid people are, etc. etc., with nothing positive to say. Maybe it's all correct from some perspective, but it's not a very useful perspective and it's definitely an annoying one to be around.

Re: The code culture problem

#39
I think the problem is an unwillingness(don't want to insult a co worker's code) or inability to form real criticism. If you can't pull the code base apart and say "this worked well" and "this part made too many assumptions to ever work right" or "is overly complicated for the task at hand" then you haven't taken enough time to understand the code in front of you.

This hits at one of my least favorite memes around here. The whole all the code I wrote six month ago is shit, and I will think that about the code I am writing now in six months. Yep, if you haven't developed the skills to determine what is good or bad about the code you wrote six months ago then A) It probably was middling code B) You aren't getting any better because you are unwilling to honestly critique your own work to look for areas that need improvement.

Re: The code culture problem

#40

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

>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.

Post reply on HN