8 ms·

The code culture problem

148 points by frausto 13y ago

rtpg 13y ago
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.
Blahah 13y ago
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. Sometimes holding people to high standards is necessary so the whole team doesn't get held back.
- pantoine 13y ago
  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).
  - gutnor 13y ago
    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.
- frausto 13y ago
  That is a fair point. And to be clear I'm not saying there is not shit code out there, because there is. I'm arguing against a type of culture that praises negativity rather than contributions.
- DominikR 13y ago
  I can't imagine any reason to not be positive and constructive, no matter how bad the code is. If the code is bad, then improve or replace it, and do your best to help that developer improve his own skills, so this wont happen again. If code output is constantly bad, then fire the developer, but there's also no reason to be condescending here. I just can't see that treating a developer (or anyone else) like shit is going to have any positive outcome considering the current market for developers, where demand is much higher than supply.
- TausAmmer 13y ago
  If a man does 5 pushups of asked 20, is he full of shit?
clueless123 13y ago
I totally agree, somehow our alpha macho instinct likes to come up and show everyone else how much we know better. Worst of all, this attitude is well rewarded on some circles. The above said, sometimes code is really shit!
zakame 13y ago
The other, darker side of this culture is that you're not calling the code shit, you're actually calling out the author of that code as shit. Sometimes, it is not really in the code or in the design. Some people are just downright evil.
marijn 13y ago
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 and understand it at all ("let's rewrite!" or "we don't touch that anymore").
- famo 13y ago
  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.
- anaphor 13y ago
  If the code really is shit then the best course of action is to work at understanding it and then refactor like crazy.
- ds9 13y ago
  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.
Toenex 13y ago
There are also many other factors that come into play when developing code, particularly if it's as part of a team working to a schedule, that have nothing to do with technical competence. In agile development you always prize something working over something pretty and the business need is firmly in the former camp so the pressure to improve code existing is alway balanced against adding 'value'. None of which is visible when you are confronted by a snapshot of the code. However, sometimes code is just shit.
eksith 13y ago
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. This "politeness is rubbish" attitude which also applies to common niceties in communication will one day be the death of us all.[1] There is truly awful code out there and it doesn't deserve commentary or any other sort of attention. Just a yanking and replacement with good code. [1] Politeness devoid of sincerity is not politeness. It is in fact the worst of all forms of rudeness.
- lucisferre 13y ago
  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-arent-enough-swear.html http://staefcraeft.blogspot.com/2013/07/linus-torvalds-there...
  - eksith 13y ago
    Dated "13 Jul 2013". I'm curious what Linus was like before he created Linux.
    - redblacktree 13y ago
      At least in the message that introduces Linux, he's much more congenial. https://www.cs.cmu.edu/~awb/linux.history.html https://www.cs.cmu.edu/~awb/linux.history.html
- AndyKelley 13y ago
  "Brogrammer" is ill-defined. It's silly to blame something on an ill-defined concept. http://gizmodo.com/5910824/theres-no-such-thing-as-a-brogrammer http://gizmodo.com/5910824/theres-no-such-thing-as-a-brogram...
mjhea0 13y ago
"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.
- lucisferre 13y ago
  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 13y ago
    [deleted]
- boomlinde 13y ago
  I don't see how you can make that conclusion from the quote.
Cthulhu_ 13y ago
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.
ahadden 13y ago
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.
- anaphor 13y ago
  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).
- gaius 13y ago
  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!
- johnnyc3po 13y ago
  You don't need tests to refactor code... unless you are an OCD programmer who needs nice little test containers for everything. And the other thing about testing, forgot to write a critical unit test? App fails, all the other tests are a moot point. It is no different then writing "legacy" code and forgetting something critical. Be careful what you read and are influenced by.
kybernetyk 13y ago
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.
- pivnicek 13y ago
  Indeed, I came across a last_day_of_the_month SQL implementation today that I showed my colleague who's instinct was that it was shit, but upon closer inspection, it seems quite clever.
- Too 13y ago
  Checking the history of the file can also be quite revealing. First version usually looks good. Later, most commits are just trying to squeeze in new functionality by changing as little as possible of the existing code. 20 check-ins later the original design is no longer relevant and mostly consists of exceptions because nobody was brave enough to refactor. Getting refactoring approved could also be hard by in certain cultures and organizations because "why change something that is proven to work in production"
jwl 13y ago
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.
drraoulduke 13y ago
This article is shi*t
bowlofpetunias 13y ago
> 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.
- babarock 13y ago
  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.
  - drtse4 13y ago
    Exactly, that "Why did he write it this weird way?" helps you understand the programmer who wrote it (his level of expertise) and gives the opportunity to analyse the tradeoffs he made. This helps discern between real shit and unpleasant code that had to be written/structured that way.
  - mgkimsal 13y ago
    "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". --------------------- You're 3 years in. In another 3-5 years (maybe more), this 'positive attitude' will (and should) go away. You'll have a much better understanding of the 'weird' ways, and will be able to tell 'quick hacks' from 'crap code' as the OP was referring to. You will have learned most of what you need to know by investigating the 'weird way', and you'll see the patterns, and you'll be at this for 15 years, and you'll be seeing the majority of stuff coming out being crap code by younger developers. It's the way of the world.
scotty79 13y ago
I 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.
- njharman 13y ago
  > it often destroys my motivation to finish what I started Shit code, mine or others, highly motivates me. To refactor/fix it. To the point I have a really hard time making targeted, single purpose commits. Because I have pride in my work, concern for the dev who has to maintain this shit after me, and understand costs of technical debt.
christkv 13y ago
I still love it when you find some "shit" code, just to realize you wrote it yourself ages ago.
- raldu 13y ago
  This is a sign of progress, actually. If you cannot find faults in the code you wrote ages ago and think it is awesome, time to find and fix some deep problems.
  - a-priori 13y ago
    Not necessarily... it's only progress if you wouldn't do the same thing again. It's one thing to be able to recognize shitty code in hindsight or in another developer's work. It's quite another to be able to catch yourself before you write shitty code and do better.
Jach 13y ago
Relevant (not-XKCD) comic: http://www.osnews.com/story/19266/WTFs_m 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.
abecedarius 13y ago
In 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.
stonemetal 13y ago
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.
badman_ting 13y ago
How about a culture of "stop fucking up". (I admit I stole this from Ted Dziuba, but it has stuck with me.) People who are willing to call things "shit" instead of being nicey-nice at least give a shit. But it is important to be intellectually honest, and not be egotistical about one's own code, which could be shit just like anyone else's.
- namenotrequired 13y ago
  >> People who are willing to call things "shit" instead of being nicey-nice at least give a shit. Or they're just adhering to the culture of calling all imperfect code shit because that's what they see others doing. >> But it is important to be intellectually honest, and not be egotistical about one's own code, which could be shit just like anyone else's. Well said.
- snom380 13y ago
  "Stop fucking up" quickly ends up with "stop taking risks" and "design by committee", which may be a good idea if you write avionics or banking software, but perhaps not in other markets.
  - njharman 13y ago
    > "stop taking risks" and "design by committee", Those are both fuck ups. So, I respectfully disagree that "stop fucking up" leads to those ever and suggest you don't understand what fucking up entails.
    - snom380 13y ago
      Those are more subtle fuck ups that the company might not notice for a long time, usually when you're eclipsed by the competition and upper management has been replaced. A better slogan might be "always make new mistakes".
- leokun 13y ago
  I don't like Dziuba's harshness sometimes, but I agree with this sentiment. Code doesn't care about your feelings, and you shouldn't either. Just write good stuff that works, and if it's not good, don't blunt the message. If you think code and programmers should respect your feelings, you'll get slow code with many bugs, and few people willing to do anything about it in order not to hurt other people's feelings. Straight up honesty is the best medicine when it comes to software. If you have a problem with this kind of honesty, find something else to do.
fogus 13y ago
In my time as a professional programmer I've come to notice a trend. It's true that there is a lot of bad code in the world and much of it is worthy of derision. That said, time after time I've noticed that when confronted with a smelly codebase junior and/or less-skilled programmers are quick to blame the code and the person who wrote it while more senior and/or highly-skilled programmers will start by placing the blame on their own lack of understanding.
- derefr 13y ago
  Junior programmers aren't aware that reading code is hard, since they've never really been forced to read much code (AFAIK there's no point in a CS course where "scour this 500KLOC non-didactic codebase for the cause of this bug and fix it" is assigned.) Because they aren't aware that reading code is hard, they think that code that's hard to read is a code smell, whether the complexity comes from obfuscation, or just the inherent complexity of the problem domain. They also don't know that they don't know this, because they've seen code that's comparatively easy to read -- why, they've written it themselves! Their implementation of only the minimal requirements of the domain is much clearer than someone else's complete solution with all its required business-warts. As such, obviously, throwing out the previous complete solution, and filling in the gap with their own minimal reimplementation, is an improvement. (They don't notice that after fixing the ensuing regression bugs, their version now bears a much stronger resemblance to the previous one....) Eventually, you read enough code that you get used to that particular "smell," and you realize that it's not really pungent in the way the other smells are. The "complex problem-domain, completely expressed" smell becomes the grease on the equipment[1] -- the sign of a well-patched and long-running system. --- [1] http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
- elliottwilliams 13y ago
  It sounds like junior devs are applying an attribution error: http://en.wikipedia.org/wiki/Fundamental_attribution_error http://en.wikipedia.org/wiki/Fundamental_attribution_error
static_typed 13y ago
Ultimately, code is like farts. It does stink, but passes with time. Also, stretching the fart analogy a bit more, as developers we always find the output of others (farts and code) to stink more than our own. Some even seem to like their own.
3pt14159 13y ago
I just give newish developers this link: http://en.wikipedia.org/wiki/Code_smell http://en.wikipedia.org/wiki/Code_smell And magically the number of "this is shit" comments decrease dramatically. The problem is that people don't like seeing easy to spot problems, but instead of giving people a guide, they complain.
jebblue 13y ago
Programmers are critical thinkers, that's why we are good at what we do. That's why no code anyone writes including our own 4 or 5 years down the line meets even our own standards. You have to be a critical thinker to get coding, to want to do it. The only down side is so much critical thinking wears us down over time. If anything, we should force ourselves to take more vacations.
mar77i 13y ago
asking people to be very specific is the first thing that should be done in any technical environment. "shit" is going down all over the place, please emphasize. asking people to be nicer in a technical environment would require similar levels of education and understanding of the tools involved. you seem to be a person that makes other people get stomack aches from bad code, so maybe you should reconsider your abilities. if you write overall good code it's inherently easier to find a bug in it than if you just stitch shit together. if you solve your problems with stackoverflow and/or huge books like "how to... in 21 days" you should maybe reconsider your career choices. in code the attention to detail is always more important than the overall intention, so why not leave it at that?
tareqak 13y ago
From my personal experience, individuals who say "this code is shit" are often far removed from the process of writing code in the first place. I wonder where the whole "Worse is Better" paradigm fits into the universe with good code, acceptable code, and "shit code".
edw519 13y ago
...when I asked my coworker to explain...why is the code shit, I couldn't get a straight answer. Maybe because there are only so many straight answers and we get tired of repeating them so often... Class A: It's too difficult for the next programmer to understand this - poor (or horrible) variable naming - poor (or horrible) function naming - repeated repeated repeated repeated code - comments don't match code - comments needed but not there - comments needed by unintelligible - unbalanced structure - poor (or horrible) choices for iterations - poor (or horrible) choices for conditionals - poor (or horrible) choices for data design/storage - poorly maintained by Programmers #2 thru x, who didn't understand it - etc., etc., etc. Class B: Poor machine performance, not by 10%, but by 10000%, because of extremely poor design and development choices. Class C: It's broken. Insufficiently tested & broken in production.
yason 13y ago
The shitty truth begins to appear when you've — way too many times, might I add — read the old code, thinking it makes sense and then feeling the pain of naivete shifting out as the code eventually turns out to make no sense. Then begin to recognize potentially shit earlier in the process and while you do enough many rounds of that, confirming your expectations, you can just look at the code and say "this is shit" and be quite confident that you're right. That's not to say that there wouldn't be a similar process working towards recognizing "When to rewrite this shit?" There is and the answer it gives is "Rarely". A seasoned programmer will balance between "this is shit" and "not rewriting this shit". And there's nothing wrong with shit, because the shit is shipping and mostly works unlike the ultimate refactoring that nobody has time to write. So it's the programmer's job to fix shit, and occasionally write new stuff that shall be deemed shit by a later fellow colleague. Instead of pointing at the vague shitty attitudes towards shit, the author should probably just roll up his sleeves and start fixing the shit.
cdmoyer 13y ago
I think this is just a general reflection of modern (internet) culture. It's easier to get "internet points" (read: facebook likes, twitter retweets, etc) by being snarky than it is by being positive.
OldSchool 13y ago
I imagine anyone who's been around for long at all has written what someone would call "shit code." Hindsight is 20/20. Imagine auto makers comparing product today with those from 50 years ago? That's about how far we've progressed in 10-15 years in this industry. Were those guys whose contemporaries were able to send people to the moon on CNC-less machine tools and computers with 4K RAM somehow doing "shit engineering?" Imagine if what someone sees as "shit code" ultimately made yesterday's coder $1000/line because it got done while there was an opportunity to sell it. Is it still "shit code?" You're not being asked to be a music critic here. Most code is written as part of a business. That said, code reviews are a great way to learn from and align with your team!
- BasDirks 13y ago
  Good point, but writing software in PHP or Java is voluntary retardation. You're holding back the advancement of our trade.
  - AlisdairO 13y ago
    > Java I call bull. Java has plenty of issues, but plenty of plus points too, particularly for large-scale development on teams that experience employee turnover. - Reasonably fast, considering the ease of development. - Genuinely fantastic tooling. - Generally discourages 'fancy' programming techniques. Obviously doesn't stop shit code getting produced, but at least tends to be relatively easy for maintenance programmers who weren't heavily involved in original development to understand. I have to use Java for some of my work, and with the correct tooling it's really not that bad. Sometimes it's fantastic - when you're maintaining someone else's code, the ability to trivially (and exhaustively) find out what code calls this code, safely refactor and so on is invaluable. Of languages in its general class, C# is significantly superior, but tied to MS if you want a full-speed VM. I'm not saying that you're likely to produce the most beautiful code of your life in Java, but compared to many other languages (+ toolchains) I find working on other people's code is rather easy.
rachelbythebay 13y ago
$query = "SELECT " + $_POST["foo"] + "..."; db_run_whatever($query); What you call that depends on what you know about the situation and the bigger picture. It doesn't change what it is, or what it implies.
drderidder 13y ago
It's not simply a code culture problem; there are tools like Programming Mess Detector, PHP Mess Detector, Findbugs etc that can quantifiably show just how crappy a lot of code is. See http://pmd.sourceforge.net/ http://pmd.sourceforge.net/
BasDirks 13y ago
This piece reminds me of Linus Torvalds. He's the kind of guy that lives these truths. Always respectful and constructive, never saying code is shit, etc etc. We need more developers like him.
- lukeschlather 13y ago
  Torvalds is BDFL. If you wrote it, it's widely acknowledged to be good, and people want to add code to it, you're entitled to tell people their contributions are unwanted. If no one other than the 6 people you're working with have ever read the code and nobody wants to add code to it, you need to really spend some time reading the code before you make a judgement call. At that point, it's better to make the code not shit than simply call it shit. In software, if you can articulate why it's bad, you can fix it. If you can't articulate why it's bad, keep it to yourself.
  - BasDirks 13y ago
    Great reply, I agree.
- etjossem 13y ago
  Are you kidding? Read this, it's a commit by Linus Torvalds: https://lkml.org/lkml/2013/7/13/132 https://lkml.org/lkml/2013/7/13/132 We need more developers like Torvalds - not because he's nice, but because he's terrifyingly experienced and completely honest in his feedback. I couldn't think of a better mentor.
  - johnjlocke 13y ago
    Just because Linus can get away with treating people like crap, doesn't mean everyone can get away with treating people like crap.
jwmoz 13y ago
You can't polish a turd.
franzwong 13y ago
It is a problem if programmers cannot give a reason why the code is shit. But most of the time they give reason, the reason is not good enough. However, I still think it is necessary to say "this is shit code".
jheriko 13y ago
my first instinct is to laugh this off because its talking about web developers... obviously all of the code is shit because its not hand optimised assembler! not sure why i hold onto this 20 years out of date mentality..
wavesounds 13y ago
This also seems like something you could get fired for. You are not just disrespecting your teammate's judgement but also your boss's judgement in hiring your teammate. Therefore you are not a team player and maybe shouldn't be on the team.
7Figures2Commas 13y ago
A toilet that doesn't flush correctly isn't a reason to complain if you're a plumber; it's your raison d'etre. And, although many don't want to recognize it, a good number of software developers are modern day plumbers. For many developers, imperfect code, which is often more likely to be result of circumstances beyond the control of the person who wrote it than downright incompetence, is the gift that keeps on giving. If business and functional requirements were always well-defined and never evolved, clients/business stakeholders completely sane, deadlines realistic, resources plentiful and "scope creep" a rare phenomenon, a lot of software developers would be unemployed, and employed ones would be more frequently undervalued.
eddyparkinson 13y ago
60% shit removal! A review removes 60-80% shit, to remove more than 80% use compounded shit removal. Compound requirements, design and code reviews to get 99%+ shit removal. finding 60% shit is not hard, every time you spot a little shit spend 3mins thinking about how to create better next ti
Qantourisc 13y ago
I'd say most code is shit. However, I'm sure people don't deliver shit code by pure choice. Unclear function purposes, time constrains, bad days, etc. Or just the plain old, "quick hack it together" to get back to the code you where really working on. We should just not feel insulted about the fact we write shit code, this doesn't mean you are a shit programmer.
zwieback 13y ago
A lot of is an age thing. I vaguely remember feeling like that but that was soo long ago. Of course there is a lot of truly crappy code but you're only allowed to complain about it if you write flawless code each time, every time out of the gate, e.g. never. Also, whatever your favorite "technology" is today is probably a bad joke to the next guy.
nsxwolf 13y ago
"If a tree falls in a forest" comes to mind. If shit code is performant, correctly solves the intended problem, is well-tested and bug-free, is it really shit code?
deleted 13y ago
[deleted]
johnnyc3po 13y ago
Too many devs writing simple applications get caught in this "my code has got to be incredibly elegant" mindset. Remember, code is a tool to create something and bring value. Don't write code for the sake of writing code for Christ's sake (my). Carmack is a fine example of a value first, elegance second type of programmer.
boomlinde 13y ago
Shit code is shit code no matter the circumstances surrounding its creation. The way I see it, the author got the solution to the problem all wrong. You should be able to criticize bad code, and if the criticism insults you, you should just swallow your pride. You aren't your code. The problem, if any, isn't the criticism itself, but the lack of explanation. If you can argue for why a piece of code is shit in a way that will help other developers, please do!
avelis 13y ago
If code is not clean we should be able to state for at least two reasons why. e.g. It breaks SRP, lacks dependency injection, not enough abstraction. Saying something is "st" usually means we lack the verbiage to describe it. Clean code is a continual process one that needs curation with care. There are times when we are reading code and it's just terrible to understand. No care was put into it. My frustration comes to when I don't see care in code. Code is not inheritedly careful. We have to make it that way.
crazygringo 13y ago
Ugh. Another "let's-act-like-everything-is-happiness-and-rainbows" post. In my experience, most of the time someone says "this is shit", it actually is, and it's indicative of serious failures in the hiring/training/code-review/management process. The only ways that companies improve at those processes are by pointing out the shit, calling it by its name, and figuring out the best ways to keep it from happening again. Having a "this is shit" culture can be GOOD -- it can hold people accountable and promote a culture of excellence. > In the end it is a culture that values negativity rather than focus on solutions. That doesn't follow. Call it shit, and then fix it. > Start by understanding the code, and then find ways to improve upon it. That means that, instead of fixing the underlying problem and making people accountable for their work, you take on the burden of cleaning after other people's shit? I don't think so. The author is correct when they say: > Don't blurt out negative assessments of others code for no reason, and with no understanding. ...Start by understanding the code But that goes without saying. Don't be too quick to judge when you don't have the facts. But once you're sure the code is shit, it's ultimately counterproductive to hide that. Most employees will only start writing better code once they're expected to, and strongly held accountable -- like most people's performance in any job. PS: To be clear, I'm not talking about disagreements over coding styles, etc. I'm talking about code with obtuse function names and no comments. I'm talking about CSS that is hack upon hack upon hack filled with negative margins and !important's. I'm talking about JavaScript that pollutes the global namespace by programmers who refuse to use "var". Or CSS declarations like "div div span div span tr td span {color:red;}". And there's a tremendous amount of this stuff out there. Stuff that there's never an excuse for.
- frausto 13y ago
  Let me clarify a bit here. I am not denying there is a LOT of shit code out there. Nor do I have a problem with calling it out, whether the code is someone else's or my own. Fair's fair. This article is arguing against a type of environment that praises negativity rather than contributions. One where the first reaction is to name something shit by default and not even offer any solutions to fix it or at the very least understand why it is shit so you don't end up making similar mistakes in the future.
- jedmeyers 13y ago
latenite4 13y ago
see a great Dilbert cartoon about a similar subject http://tinyurl.com/av3ennj http://tinyurl.com/av3ennj
swalsh 13y ago
Kind of reminds me of a story from today. I have about a 70 page design document, laying out exactly how a new system i'm building will work. I've built something very similar in the past at a previous company, so this design is coming from a few years of learning what doesn't work. As I was trying to explain some of my, well non conventional ideas, another coworker pokes his head over the cube, and calls the design crap. This of course is nothing new, its almost a game for this particular engineer. In the end, I walked away trying to avoid the conversation. It felt emotional though, and frankly hurt my confidence (while probably inflating his own) It kind of made me think of the phrase "no one ever got fired for choosing IBM" I could have chosen the obvious design, and gone forward. No one would have debated it. However I've done that in the past, and I've seen the terrible problems that come from it. My new design is an attempt to avoid those problems. The attitude really pisses me off though, and I find it extremely counter productive.
- ser0 13y ago
  I think you can use the co-worker to your advantage. One thing we must all learn is how to defend and justify our decisions. This can either be done before or after implementation, which is what I believe the post is talking about. That is, people criticising others' implementation decisions with limited context. Most of us have read stories of Gates or Jobs dressing down employees that are unprepared. You could consult your co-worker before presenting in the future; assuming you can develop your relationship with him to the point where there is no malice in such an interaction. On the other hand, I do also recognise that some people just like to mess with others. In such circumstances, if there are no other political concerns, I would simply ask the person the come up with an alternative solution, then argue the alternative on its merits vs. what you have designed. Given your 70 pages of documentation, a simple pros vs cons list that takes into account goals of the project for various timeframes and scales should result in a clear winner. Or should both designs be of similar value, then there is little point in changing your documentation anyway.
mgonzo 13y ago
Except usually the code is shit, and that's ok. Sometimes I'm even talking about my own code and that's ok too. The first step to fixing a problem is admitting the problem exists. Attempting to cover it up it with words like, "well I'm sure there is a good reason for that" or "Hrm that could be better but I know we had crazy deadlines." Are just excuses and don't really help. If looks like shit and smells like shit... well it's probably shit. We are all big kids here, no need to sugar coat things.
bob99 13y ago
Good article, couldn't agree more. Its about time someone spoke up about the extreme negativity that has become coding culture. I've worked in companies with very negative developer culture and more positive developer culture and found the latter to produce far superior software (on time, in budget, less bugs etc.).

148 points by frausto 13y ago

rtpg 13y ago

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.

Blahah 13y ago

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. Sometimes holding people to high standards is necessary so the whole team doesn't get held back.

pantoine 13y ago
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).
- gutnor 13y ago
  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.
frausto 13y ago
That is a fair point. And to be clear I'm not saying there is not shit code out there, because there is. I'm arguing against a type of culture that praises negativity rather than contributions.
DominikR 13y ago
I can't imagine any reason to not be positive and constructive, no matter how bad the code is. If the code is bad, then improve or replace it, and do your best to help that developer improve his own skills, so this wont happen again. If code output is constantly bad, then fire the developer, but there's also no reason to be condescending here. I just can't see that treating a developer (or anyone else) like shit is going to have any positive outcome considering the current market for developers, where demand is much higher than supply.
TausAmmer 13y ago
If a man does 5 pushups of asked 20, is he full of shit?

clueless123 13y ago

I totally agree, somehow our alpha macho instinct likes to come up and show everyone else how much we know better. Worst of all, this attitude is well rewarded on some circles. The above said, sometimes code is really shit!

zakame 13y ago

The other, darker side of this culture is that you're not calling the code shit, you're actually calling out the author of that code as shit. Sometimes, it is not really in the code or in the design. Some people are just downright evil.

marijn 13y ago

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 and understand it at all ("let's rewrite!" or "we don't touch that anymore").

famo 13y ago
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.
anaphor 13y ago
If the code really is shit then the best course of action is to work at understanding it and then refactor like crazy.
ds9 13y ago
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.

Toenex 13y ago

There are also many other factors that come into play when developing code, particularly if it's as part of a team working to a schedule, that have nothing to do with technical competence. In agile development you always prize something working over something pretty and the business need is firmly in the former camp so the pressure to improve code existing is alway balanced against adding 'value'. None of which is visible when you are confronted by a snapshot of the code. However, sometimes code is just shit.

eksith 13y ago

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. This "politeness is rubbish" attitude which also applies to common niceties in communication will one day be the death of us all.[1] There is truly awful code out there and it doesn't deserve commentary or any other sort of attention. Just a yanking and replacement with good code. [1] Politeness devoid of sincerity is not politeness. It is in fact the worst of all forms of rudeness.

lucisferre 13y ago
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-arent-enough-swear.html http://staefcraeft.blogspot.com/2013/07/linus-torvalds-there...
- eksith 13y ago
  Dated "13 Jul 2013". I'm curious what Linus was like before he created Linux.
  - redblacktree 13y ago
    At least in the message that introduces Linux, he's much more congenial. https://www.cs.cmu.edu/~awb/linux.history.html https://www.cs.cmu.edu/~awb/linux.history.html
AndyKelley 13y ago
"Brogrammer" is ill-defined. It's silly to blame something on an ill-defined concept. http://gizmodo.com/5910824/theres-no-such-thing-as-a-brogrammer http://gizmodo.com/5910824/theres-no-such-thing-as-a-brogram...

mjhea0 13y ago

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

lucisferre 13y ago
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 13y ago
  [deleted]
boomlinde 13y ago
I don't see how you can make that conclusion from the quote.

Cthulhu_ 13y ago

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.

ahadden 13y ago

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.

anaphor 13y ago
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).
gaius 13y ago
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!
johnnyc3po 13y ago
You don't need tests to refactor code... unless you are an OCD programmer who needs nice little test containers for everything. And the other thing about testing, forgot to write a critical unit test? App fails, all the other tests are a moot point. It is no different then writing "legacy" code and forgetting something critical. Be careful what you read and are influenced by.

kybernetyk 13y ago

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.

pivnicek 13y ago
Indeed, I came across a last_day_of_the_month SQL implementation today that I showed my colleague who's instinct was that it was shit, but upon closer inspection, it seems quite clever.
Too 13y ago
Checking the history of the file can also be quite revealing. First version usually looks good. Later, most commits are just trying to squeeze in new functionality by changing as little as possible of the existing code. 20 check-ins later the original design is no longer relevant and mostly consists of exceptions because nobody was brave enough to refactor. Getting refactoring approved could also be hard by in certain cultures and organizations because "why change something that is proven to work in production"

jwl 13y ago

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.

drraoulduke 13y ago

This article is shi*t

bowlofpetunias 13y ago

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

babarock 13y ago
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.
- drtse4 13y ago
  Exactly, that "Why did he write it this weird way?" helps you understand the programmer who wrote it (his level of expertise) and gives the opportunity to analyse the tradeoffs he made. This helps discern between real shit and unpleasant code that had to be written/structured that way.
- mgkimsal 13y ago
  "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". --------------------- You're 3 years in. In another 3-5 years (maybe more), this 'positive attitude' will (and should) go away. You'll have a much better understanding of the 'weird' ways, and will be able to tell 'quick hacks' from 'crap code' as the OP was referring to. You will have learned most of what you need to know by investigating the 'weird way', and you'll see the patterns, and you'll be at this for 15 years, and you'll be seeing the majority of stuff coming out being crap code by younger developers. It's the way of the world.

scotty79 13y ago

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

njharman 13y ago
> it often destroys my motivation to finish what I started Shit code, mine or others, highly motivates me. To refactor/fix it. To the point I have a really hard time making targeted, single purpose commits. Because I have pride in my work, concern for the dev who has to maintain this shit after me, and understand costs of technical debt.

christkv 13y ago

I still love it when you find some "shit" code, just to realize you wrote it yourself ages ago.

raldu 13y ago
This is a sign of progress, actually. If you cannot find faults in the code you wrote ages ago and think it is awesome, time to find and fix some deep problems.
- a-priori 13y ago
  Not necessarily... it's only progress if you wouldn't do the same thing again. It's one thing to be able to recognize shitty code in hindsight or in another developer's work. It's quite another to be able to catch yourself before you write shitty code and do better.

Jach 13y ago

Relevant (not-XKCD) comic: http://www.osnews.com/story/19266/WTFs_m 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.

abecedarius 13y ago

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

stonemetal 13y ago

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.

badman_ting 13y ago

How about a culture of "stop fucking up". (I admit I stole this from Ted Dziuba, but it has stuck with me.) People who are willing to call things "shit" instead of being nicey-nice at least give a shit. But it is important to be intellectually honest, and not be egotistical about one's own code, which could be shit just like anyone else's.

namenotrequired 13y ago
>> People who are willing to call things "shit" instead of being nicey-nice at least give a shit. Or they're just adhering to the culture of calling all imperfect code shit because that's what they see others doing. >> But it is important to be intellectually honest, and not be egotistical about one's own code, which could be shit just like anyone else's. Well said.
snom380 13y ago
"Stop fucking up" quickly ends up with "stop taking risks" and "design by committee", which may be a good idea if you write avionics or banking software, but perhaps not in other markets.
- njharman 13y ago
  > "stop taking risks" and "design by committee", Those are both fuck ups. So, I respectfully disagree that "stop fucking up" leads to those ever and suggest you don't understand what fucking up entails.
  - snom380 13y ago
    Those are more subtle fuck ups that the company might not notice for a long time, usually when you're eclipsed by the competition and upper management has been replaced. A better slogan might be "always make new mistakes".
leokun 13y ago
I don't like Dziuba's harshness sometimes, but I agree with this sentiment. Code doesn't care about your feelings, and you shouldn't either. Just write good stuff that works, and if it's not good, don't blunt the message. If you think code and programmers should respect your feelings, you'll get slow code with many bugs, and few people willing to do anything about it in order not to hurt other people's feelings. Straight up honesty is the best medicine when it comes to software. If you have a problem with this kind of honesty, find something else to do.

fogus 13y ago

In my time as a professional programmer I've come to notice a trend. It's true that there is a lot of bad code in the world and much of it is worthy of derision. That said, time after time I've noticed that when confronted with a smelly codebase junior and/or less-skilled programmers are quick to blame the code and the person who wrote it while more senior and/or highly-skilled programmers will start by placing the blame on their own lack of understanding.

derefr 13y ago
Junior programmers aren't aware that reading code is hard, since they've never really been forced to read much code (AFAIK there's no point in a CS course where "scour this 500KLOC non-didactic codebase for the cause of this bug and fix it" is assigned.) Because they aren't aware that reading code is hard, they think that code that's hard to read is a code smell, whether the complexity comes from obfuscation, or just the inherent complexity of the problem domain. They also don't know that they don't know this, because they've seen code that's comparatively easy to read -- why, they've written it themselves! Their implementation of only the minimal requirements of the domain is much clearer than someone else's complete solution with all its required business-warts. As such, obviously, throwing out the previous complete solution, and filling in the gap with their own minimal reimplementation, is an improvement. (They don't notice that after fixing the ensuing regression bugs, their version now bears a much stronger resemblance to the previous one....) Eventually, you read enough code that you get used to that particular "smell," and you realize that it's not really pungent in the way the other smells are. The "complex problem-domain, completely expressed" smell becomes the grease on the equipment[1] -- the sign of a well-patched and long-running system. --- [1] http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
elliottwilliams 13y ago
It sounds like junior devs are applying an attribution error: http://en.wikipedia.org/wiki/Fundamental_attribution_error http://en.wikipedia.org/wiki/Fundamental_attribution_error

static_typed 13y ago

Ultimately, code is like farts. It does stink, but passes with time. Also, stretching the fart analogy a bit more, as developers we always find the output of others (farts and code) to stink more than our own. Some even seem to like their own.

3pt14159 13y ago

I just give newish developers this link: http://en.wikipedia.org/wiki/Code_smell http://en.wikipedia.org/wiki/Code_smell And magically the number of "this is shit" comments decrease dramatically. The problem is that people don't like seeing easy to spot problems, but instead of giving people a guide, they complain.

jebblue 13y ago

Programmers are critical thinkers, that's why we are good at what we do. That's why no code anyone writes including our own 4 or 5 years down the line meets even our own standards. You have to be a critical thinker to get coding, to want to do it. The only down side is so much critical thinking wears us down over time. If anything, we should force ourselves to take more vacations.

mar77i 13y ago

asking people to be very specific is the first thing that should be done in any technical environment. "shit" is going down all over the place, please emphasize. asking people to be nicer in a technical environment would require similar levels of education and understanding of the tools involved. you seem to be a person that makes other people get stomack aches from bad code, so maybe you should reconsider your abilities. if you write overall good code it's inherently easier to find a bug in it than if you just stitch shit together. if you solve your problems with stackoverflow and/or huge books like "how to... in 21 days" you should maybe reconsider your career choices. in code the attention to detail is always more important than the overall intention, so why not leave it at that?

tareqak 13y ago

From my personal experience, individuals who say "this code is shit" are often far removed from the process of writing code in the first place. I wonder where the whole "Worse is Better" paradigm fits into the universe with good code, acceptable code, and "shit code".

edw519 13y ago

...when I asked my coworker to explain...why is the code shit, I couldn't get a straight answer. Maybe because there are only so many straight answers and we get tired of repeating them so often... Class A: It's too difficult for the next programmer to understand this - poor (or horrible) variable naming - poor (or horrible) function naming - repeated repeated repeated repeated code - comments don't match code - comments needed but not there - comments needed by unintelligible - unbalanced structure - poor (or horrible) choices for iterations - poor (or horrible) choices for conditionals - poor (or horrible) choices for data design/storage - poorly maintained by Programmers #2 thru x, who didn't understand it - etc., etc., etc. Class B: Poor machine performance, not by 10%, but by 10000%, because of extremely poor design and development choices. Class C: It's broken. Insufficiently tested & broken in production.

yason 13y ago

The shitty truth begins to appear when you've — way too many times, might I add — read the old code, thinking it makes sense and then feeling the pain of naivete shifting out as the code eventually turns out to make no sense. Then begin to recognize potentially shit earlier in the process and while you do enough many rounds of that, confirming your expectations, you can just look at the code and say "this is shit" and be quite confident that you're right. That's not to say that there wouldn't be a similar process working towards recognizing "When to rewrite this shit?" There is and the answer it gives is "Rarely". A seasoned programmer will balance between "this is shit" and "not rewriting this shit". And there's nothing wrong with shit, because the shit is shipping and mostly works unlike the ultimate refactoring that nobody has time to write. So it's the programmer's job to fix shit, and occasionally write new stuff that shall be deemed shit by a later fellow colleague. Instead of pointing at the vague shitty attitudes towards shit, the author should probably just roll up his sleeves and start fixing the shit.

cdmoyer 13y ago

I think this is just a general reflection of modern (internet) culture. It's easier to get "internet points" (read: facebook likes, twitter retweets, etc) by being snarky than it is by being positive.

OldSchool 13y ago

I imagine anyone who's been around for long at all has written what someone would call "shit code." Hindsight is 20/20. Imagine auto makers comparing product today with those from 50 years ago? That's about how far we've progressed in 10-15 years in this industry. Were those guys whose contemporaries were able to send people to the moon on CNC-less machine tools and computers with 4K RAM somehow doing "shit engineering?" Imagine if what someone sees as "shit code" ultimately made yesterday's coder $1000/line because it got done while there was an opportunity to sell it. Is it still "shit code?" You're not being asked to be a music critic here. Most code is written as part of a business. That said, code reviews are a great way to learn from and align with your team!

BasDirks 13y ago
Good point, but writing software in PHP or Java is voluntary retardation. You're holding back the advancement of our trade.
- AlisdairO 13y ago
  > Java I call bull. Java has plenty of issues, but plenty of plus points too, particularly for large-scale development on teams that experience employee turnover. - Reasonably fast, considering the ease of development. - Genuinely fantastic tooling. - Generally discourages 'fancy' programming techniques. Obviously doesn't stop shit code getting produced, but at least tends to be relatively easy for maintenance programmers who weren't heavily involved in original development to understand. I have to use Java for some of my work, and with the correct tooling it's really not that bad. Sometimes it's fantastic - when you're maintaining someone else's code, the ability to trivially (and exhaustively) find out what code calls this code, safely refactor and so on is invaluable. Of languages in its general class, C# is significantly superior, but tied to MS if you want a full-speed VM. I'm not saying that you're likely to produce the most beautiful code of your life in Java, but compared to many other languages (+ toolchains) I find working on other people's code is rather easy.

rachelbythebay 13y ago

$query = "SELECT " + $_POST["foo"] + "..."; db_run_whatever($query); What you call that depends on what you know about the situation and the bigger picture. It doesn't change what it is, or what it implies.

drderidder 13y ago

It's not simply a code culture problem; there are tools like Programming Mess Detector, PHP Mess Detector, Findbugs etc that can quantifiably show just how crappy a lot of code is. See http://pmd.sourceforge.net/ http://pmd.sourceforge.net/

BasDirks 13y ago

This piece reminds me of Linus Torvalds. He's the kind of guy that lives these truths. Always respectful and constructive, never saying code is shit, etc etc. We need more developers like him.

lukeschlather 13y ago
Torvalds is BDFL. If you wrote it, it's widely acknowledged to be good, and people want to add code to it, you're entitled to tell people their contributions are unwanted. If no one other than the 6 people you're working with have ever read the code and nobody wants to add code to it, you need to really spend some time reading the code before you make a judgement call. At that point, it's better to make the code not shit than simply call it shit. In software, if you can articulate why it's bad, you can fix it. If you can't articulate why it's bad, keep it to yourself.
- BasDirks 13y ago
  Great reply, I agree.
etjossem 13y ago
Are you kidding? Read this, it's a commit by Linus Torvalds: https://lkml.org/lkml/2013/7/13/132 https://lkml.org/lkml/2013/7/13/132 We need more developers like Torvalds - not because he's nice, but because he's terrifyingly experienced and completely honest in his feedback. I couldn't think of a better mentor.
- johnjlocke 13y ago
  Just because Linus can get away with treating people like crap, doesn't mean everyone can get away with treating people like crap.

jwmoz 13y ago

You can't polish a turd.

franzwong 13y ago

It is a problem if programmers cannot give a reason why the code is shit. But most of the time they give reason, the reason is not good enough. However, I still think it is necessary to say "this is shit code".

jheriko 13y ago

my first instinct is to laugh this off because its talking about web developers... obviously all of the code is shit because its not hand optimised assembler! not sure why i hold onto this 20 years out of date mentality..

wavesounds 13y ago

This also seems like something you could get fired for. You are not just disrespecting your teammate's judgement but also your boss's judgement in hiring your teammate. Therefore you are not a team player and maybe shouldn't be on the team.

7Figures2Commas 13y ago

A toilet that doesn't flush correctly isn't a reason to complain if you're a plumber; it's your raison d'etre. And, although many don't want to recognize it, a good number of software developers are modern day plumbers. For many developers, imperfect code, which is often more likely to be result of circumstances beyond the control of the person who wrote it than downright incompetence, is the gift that keeps on giving. If business and functional requirements were always well-defined and never evolved, clients/business stakeholders completely sane, deadlines realistic, resources plentiful and "scope creep" a rare phenomenon, a lot of software developers would be unemployed, and employed ones would be more frequently undervalued.

eddyparkinson 13y ago

60% shit removal! A review removes 60-80% shit, to remove more than 80% use compounded shit removal. Compound requirements, design and code reviews to get 99%+ shit removal. finding 60% shit is not hard, every time you spot a little shit spend 3mins thinking about how to create better next ti

Qantourisc 13y ago

I'd say most code is shit. However, I'm sure people don't deliver shit code by pure choice. Unclear function purposes, time constrains, bad days, etc. Or just the plain old, "quick hack it together" to get back to the code you where really working on. We should just not feel insulted about the fact we write shit code, this doesn't mean you are a shit programmer.

zwieback 13y ago

A lot of is an age thing. I vaguely remember feeling like that but that was soo long ago. Of course there is a lot of truly crappy code but you're only allowed to complain about it if you write flawless code each time, every time out of the gate, e.g. never. Also, whatever your favorite "technology" is today is probably a bad joke to the next guy.

nsxwolf 13y ago

"If a tree falls in a forest" comes to mind. If shit code is performant, correctly solves the intended problem, is well-tested and bug-free, is it really shit code?

deleted 13y ago

[deleted]

johnnyc3po 13y ago

Too many devs writing simple applications get caught in this "my code has got to be incredibly elegant" mindset. Remember, code is a tool to create something and bring value. Don't write code for the sake of writing code for Christ's sake (my). Carmack is a fine example of a value first, elegance second type of programmer.

boomlinde 13y ago

Shit code is shit code no matter the circumstances surrounding its creation. The way I see it, the author got the solution to the problem all wrong. You should be able to criticize bad code, and if the criticism insults you, you should just swallow your pride. You aren't your code. The problem, if any, isn't the criticism itself, but the lack of explanation. If you can argue for why a piece of code is shit in a way that will help other developers, please do!

avelis 13y ago

If code is not clean we should be able to state for at least two reasons why. e.g. It breaks SRP, lacks dependency injection, not enough abstraction. Saying something is "st" usually means we lack the verbiage to describe it. Clean code is a continual process one that needs curation with care. There are times when we are reading code and it's just terrible to understand. No care was put into it. My frustration comes to when I don't see care in code. Code is not inheritedly careful. We have to make it that way.

crazygringo 13y ago

Ugh. Another "let's-act-like-everything-is-happiness-and-rainbows" post. In my experience, most of the time someone says "this is shit", it actually is, and it's indicative of serious failures in the hiring/training/code-review/management process. The only ways that companies improve at those processes are by pointing out the shit, calling it by its name, and figuring out the best ways to keep it from happening again. Having a "this is shit" culture can be GOOD -- it can hold people accountable and promote a culture of excellence. > In the end it is a culture that values negativity rather than focus on solutions. That doesn't follow. Call it shit, and then fix it. > Start by understanding the code, and then find ways to improve upon it. That means that, instead of fixing the underlying problem and making people accountable for their work, you take on the burden of cleaning after other people's shit? I don't think so. The author is correct when they say: > Don't blurt out negative assessments of others code for no reason, and with no understanding. ...Start by understanding the code But that goes without saying. Don't be too quick to judge when you don't have the facts. But once you're sure the code is shit, it's ultimately counterproductive to hide that. Most employees will only start writing better code once they're expected to, and strongly held accountable -- like most people's performance in any job. PS: To be clear, I'm not talking about disagreements over coding styles, etc. I'm talking about code with obtuse function names and no comments. I'm talking about CSS that is hack upon hack upon hack filled with negative margins and !important's. I'm talking about JavaScript that pollutes the global namespace by programmers who refuse to use "var". Or CSS declarations like "div div span div span tr td span {color:red;}". And there's a tremendous amount of this stuff out there. Stuff that there's never an excuse for.

frausto 13y ago
Let me clarify a bit here. I am not denying there is a LOT of shit code out there. Nor do I have a problem with calling it out, whether the code is someone else's or my own. Fair's fair. This article is arguing against a type of environment that praises negativity rather than contributions. One where the first reaction is to name something shit by default and not even offer any solutions to fix it or at the very least understand why it is shit so you don't end up making similar mistakes in the future.
jedmeyers 13y ago

latenite4 13y ago

see a great Dilbert cartoon about a similar subject http://tinyurl.com/av3ennj http://tinyurl.com/av3ennj

swalsh 13y ago

Kind of reminds me of a story from today. I have about a 70 page design document, laying out exactly how a new system i'm building will work. I've built something very similar in the past at a previous company, so this design is coming from a few years of learning what doesn't work. As I was trying to explain some of my, well non conventional ideas, another coworker pokes his head over the cube, and calls the design crap. This of course is nothing new, its almost a game for this particular engineer. In the end, I walked away trying to avoid the conversation. It felt emotional though, and frankly hurt my confidence (while probably inflating his own) It kind of made me think of the phrase "no one ever got fired for choosing IBM" I could have chosen the obvious design, and gone forward. No one would have debated it. However I've done that in the past, and I've seen the terrible problems that come from it. My new design is an attempt to avoid those problems. The attitude really pisses me off though, and I find it extremely counter productive.

ser0 13y ago
I think you can use the co-worker to your advantage. One thing we must all learn is how to defend and justify our decisions. This can either be done before or after implementation, which is what I believe the post is talking about. That is, people criticising others' implementation decisions with limited context. Most of us have read stories of Gates or Jobs dressing down employees that are unprepared. You could consult your co-worker before presenting in the future; assuming you can develop your relationship with him to the point where there is no malice in such an interaction. On the other hand, I do also recognise that some people just like to mess with others. In such circumstances, if there are no other political concerns, I would simply ask the person the come up with an alternative solution, then argue the alternative on its merits vs. what you have designed. Given your 70 pages of documentation, a simple pros vs cons list that takes into account goals of the project for various timeframes and scales should result in a clear winner. Or should both designs be of similar value, then there is little point in changing your documentation anyway.

mgonzo 13y ago

Except usually the code is shit, and that's ok. Sometimes I'm even talking about my own code and that's ok too. The first step to fixing a problem is admitting the problem exists. Attempting to cover it up it with words like, "well I'm sure there is a good reason for that" or "Hrm that could be better but I know we had crazy deadlines." Are just excuses and don't really help. If looks like shit and smells like shit... well it's probably shit. We are all big kids here, no need to sugar coat things.

bob99 13y ago

Good article, couldn't agree more. Its about time someone spoke up about the extreme negativity that has become coding culture. I've worked in companies with very negative developer culture and more positive developer culture and found the latter to produce far superior software (on time, in budget, less bugs etc.).