As developers we might need to work on not taking bugs and criticism of our code too personal. I know I feel that way sometimes, when bugs or bad design is found in my work it is easy to get defensive and take it is a personal attack - which usually is not a constructive approach.
The code culture problem
21–30 of 162 posts
Re: The code culture problem
#22This 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…
I think "shit code" usually falls into two broad categories (or both). Either the developer has a poor understanding of the problem they're trying to solve and comes up with something that is a massive hack/barely works (see: workaround oriented programming) or it was written in a style that the person reading the code considers "stupid" or "outdated" (this would fall into the legacy code category).
Re: The code culture problem
#23"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.
Re: The code culture problem
#24This article is shi*t
Re: The code culture problem
#25> 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 they were developing in and the tools they were using to do it, and actually gave crap".
The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear.
I completely agree with the point the author is trying to make about the attitude problem, especially amongst coworkers, but let's not gloss over the fact that halfway decent code written by competent developers is still very, very rare.
Most code out there is shit code. Denying it is not going to help either.
Re: The code culture problem
#26I almost never look at somebodys code and think it's shit. Sometimes I think some ideas are not the best possible ones in given context. But I almost exclusively think "this is shit" while I'm looking at my own code. And I agree that that feeling is a problem as it often destroys my motivation to finish what I started.
Re: The code culture problem
#27I still love it when you find some "shit" code, just to realize you wrote it yourself ages ago.
Re: The code culture problem
#28Behold, 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...
Dated "13 Jul 2013". I'm curious what Linus was like before he created Linux.
Re: The code culture problem
#29Relevant (not-XKCD) comic: http://www.osnews.com/story/19266/WTFs_m
I'm not opposed to calling out shit, even in my own work, but you ought to be able to explain the smell, even if it's something silly like curly brace location. (Ideally it's shit for a better reason... there usually is.) Besides if a rant doesn't immediately follow the declaration, you can't really claim to care all that much. If you're working on the Linux kernel and get flamed by Linus consider yourself lucky! It's because he cares. (And thinks there's still hope for you to do better.) I don't mind the rantless half-hearted calls of bullshit either; rather than leading to everyone feeling bad and trying to feel less bad by trying to make other people feel bad, I think it would sooner lead to more cynicism with insults and less taking offense and feeling bad.
Re: The code culture problem
#30In my experience average code quality has considerably improved in the last, say, 20 years, I'd guess because of open source and the internet spreading higher standards, hardware and systems improvement relaxing efficiency constraints, and better education that just takes time to spread. When I started my job after college, the first day they handed me a 20-page DOS batch file to modify, and yes, part of that's my career trajectory, but I think there's more to it. I didn't say so, but in my own head "this is shit" was among my reactions, and shit these days has to work to measure up.