The code culture problem • Hacker News Board

Re: The code culture problem

#11

Post by gutnor » Thu, Sep 05, 2013, 12:36 PM UTC

pantoine wrote: post #3

Blahah wrote: post #2

Point taken - it's very easy to feel like someone else's code is bad if it's hard to understand or does something in a way you think isn't the best, or even good. Maybe being nice is helpful sometimes. On the other hand, sometimes code really is just shit. Being positive and saying "this is a good start, let's go through it and see if we can improve upon it" might be a massive waste of time if it's really shit. Somet…

I would take your point forward and say if the code is hard too read then is it shit. There is a reason that you are reading it: you are maintaining it, adding a feature or trying to fix a bug. If it is not easy to read then it makes this harder and that makes code bad and increases the chances of the editor making a mistake and breaking the system. (Or just making your day bad).

Is it hard to read or hard to understand ? Generally when we say "hard to read" we mean both. Especially because as you said, you read the code for a purpose, and that purpose is very often business related rather than purely aesthetic.

Making the code easy to read is simply a technical matter, an intrinsic quality of the code. However, your code cannot be easier to understand than the business it models.

To convince yourself, have a look at some (good) framework like a HTTP Server, ORM, or browser, ... Their code is generally miles away from what you expect and hard to read if you do not dedicate days or weeks to them. But it is not due to bad code but due to the fact that you are aware of only a tiny fraction of the problem they solve.

EDIT: (I realise I didn't make a point) My point is that it is not a hard rule. If you are experimented with the business, familiar (a bit) with the code and it is still hard to read that is the sign of trouble.

Re: The code culture problem

#12

Post by TausAmmer » Thu, Sep 05, 2013, 12:48 PM UTC

Blahah wrote: post #2

Point taken - it's very easy to feel like someone else's code is bad if it's hard to understand or does something in a way you think isn't the best, or even good. Maybe being nice is helpful sometimes. On the other hand, sometimes code really is just shit. Being positive and saying "this is a good start, let's go through it and see if we can improve upon it" might be a massive waste of time if it's really shit. Somet…

If a man does 5 pushups of asked 20, is he full of shit?

Re: The code culture problem

#13

Post by mjhea0 » Thu, Sep 05, 2013, 12:50 PM UTC

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

Re: The code culture problem

#14

Post by Cthulhu_ » Thu, Sep 05, 2013, 12:56 PM UTC

I don't see it as a code culture problem, or hell, even a problem in itself. It's a dude issue. Dudes can be judgmental, and if not held back by some corporate culture, if not applying filters of courteousness and being the better man, or by simply being in a certain environment where certain behaviour is frowned upon, things like this will appear.

On the one side, it's a bad thing. On the other, it's stereotypical dudely behavior, and should be made fun of. "This is shit!" is, from my point of view, a way to observe that code 'feels' off, and an exclamation of frustration in that the reader can't understand it right away - and apparently doesn't have or can't take the time needed to dig in and understand it deeper.

I often go for gut feelings in judging code (this is shit!) too, so I can understand. I can understand the frustration too when one can't spend the time to understand and fix it - besides, someone else wrote it, someone else should fix it.

tl;dr, it's complicated. If someone exclaims "this is shit", go and investigate. Sit / pair with the person, walk through the code - or even better, if possible, find the person that wrote it - and either make it unshit, or make the person making the observation understand why it's not shit.

Re: The code culture problem

#15

Post by rtpg » Thu, Sep 05, 2013, 1:00 PM UTC

I've always tried to go the opposite route when reading code from others. I'm the first (well maybe not the first but I'm at least close enough up the front of the line to see the first) to admit when I don't understand it, and when I go ask the guys who wrote it, I make this clear.

Usually I find talking like this helps people admit when code is just bad or they try to clarify it. I've found it makes asking whether it's ok to do complete rewrites a lot simpler.

Re: The code culture problem

#16

Post by famo » Thu, Sep 05, 2013, 1:07 PM UTC

marijn wrote: 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…

Yeah, I can agree with this. For me the scenario starts with reading somebody else's code and thinking it's horrendous. I'll then get this nagging feeling that the problem may instead be me not comprehending the code well enough, or not seeing the greater context in which the supposedly bad code is meant to sit. Frequently, after further investigation, the code turns out to be not as bad as I originally thought. It's almost like a judgement without all the facts / can't see the florist for the flowers kind of thing. I'm looking at that small piece of code through an aperture that blurs the bigger picture, if you widen it a little further you may see that the code was written in a certain way in order to coalesce with the rest of the code base. Or widen it further still and see that it was written poorly because it needed to be done quickly, but that poorly written code may have facilitated the first 1000 sales of the product. I won't listen to someone who trash talks another coder or a former employee for their work. It happened the other day at my job, the new guy trash talked some ops work belonging to the guy he replaced. That work has been keeping our site available for the past five years, still waiting for the new guy's road tested commits.

Re: The code culture problem

#17

Post by ahadden » Thu, Sep 05, 2013, 1:08 PM UTC

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 retrain ourselves to say that "this code has no tests." It's more productive and points us to a direction out of the situation and prevents us from getting in the situation to begin with.

I suppose some might argue that shit code is not necessarily legacy code or vice-versa. Perhaps, but in either case the first step in improving it is to get it under test.

Re: The code culture problem

#18

Post by anaphor » Thu, Sep 05, 2013, 1:08 PM UTC

marijn wrote: 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…

If the code really is shit then the best course of action is to work at understanding it and then refactor like crazy.

Re: The code culture problem

#19

Post by lucisferre » Thu, Sep 05, 2013, 1:09 PM UTC

eksith wrote: post #10

Behold, the aftermath of the brogrammer. What was seen here is a particularly insidious, caustic and ultimately, demoralizing and self-defeating attitude from your colleague (and something I've seen routinely on HN). I don't particularly think he was in any way truly convinced that it was deserving of it, however it must be thrashed in accordance with a self selected pecking order in order to assert his dominance. Th…

I don't see how this has anything to do with the brogrammer fad (as annoying as that was/is). People have been talking this way about code for a lot longer. I'll throw out one of Linus' gems as an example [1].

[1] http://staefcraeft.blogspot.com/2013/07/linus-torvalds-there...

Re: The code culture problem

#20

Post by kybernetyk » Thu, Sep 05, 2013, 1:12 PM UTC

Some years ago I was doing paid for code reviews. I learned many things but one particularly relevant to this article is: You can only tell if code is shit after you have dug through it for at least a few days.

Sure there are the obvious mistakes like non-idiomatic code style. But that's easy to spot. But for anything that is related to the problem domain and not the language itself you need to dig deeper. Because there might be a very good reason why something is done the way it is done. And later you might think: Hey, that's actually a pretty good solution.

Wading through piles of code by dozens of different developers made me humble and nowadays I think twice before calling something bad.