
The code culture problem - frausto
http://www.fraustollc.com/blog/shit_code/
======
bowlofpetunias
> _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.

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

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

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

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

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

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

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

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

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

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

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

~~~
auvrw
> all except his own, of course.

yeah, if you're going to talk bad about anyone's code, start with your own.
not even the things you wrote a few months ago, but like even today, writing
xml schemas for a rest api, the whole time i'm thinking about all the ways the
decisions i'm making are going to come back and bite me in the ass. not
because i'm inexperienced but because i've written and worked with schemas and
specs for interprocess communication before and know that any changes to the
schema will require edits to multiple codebases and the time and effort to
make some of those changes can be frightening.

i guess this is what fred brooks calls "the second system effect." it'll
probably turn out that there's some other more terrible problem with the
current system that i'm not even seeing because i'm overly concerned about the
communication protocol on top and not the databases underneath or concurrency
off to the side somewhere.

how many systems of some particular type does one have to build before not
writing shit on the first pass? because, like, yes, the code freely available
to anyone with a quick `apt-get source` is often of _much_ higher quality than
some things hidden in multinational corporations' private repos. so everyone
can have some idea of what good code looks like now, but i am personally
finding creating much more difficult than verifying and fear that it's going
to take a lot of time to narrow that gap.

is it really necessary to work on like 8 processors before doing what someone
like ivan godard does? maybe just 4 or 5 projects (which translates into about
a decade, mind you) is enough before the "i'm fucking shit up" jitters pass
for any particular type of system?

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

------
eksith
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
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...](http://staefcraeft.blogspot.com/2013/07/linus-torvalds-there-arent-
enough-swear.html)

~~~
eksith
Dated "13 Jul 2013". I'm curious what Linus was like before he created Linux.

~~~
redblacktree
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)

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

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

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

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

------
fogus
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
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)

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

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

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

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

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

------
OldSchool
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
Good point, but writing software in PHP or Java is voluntary retardation.
You're holding back the advancement of our trade.

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

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

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

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

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

~~~
jedmeyers
No way "while bool.toString().getLength() > 4" can be a shit code! It works,
what else do you need? Learn to understand first.

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

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

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

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

------
mar77i
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?

------
rachelbythebay

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

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

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

------
clueless123
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!

------
avelis
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 "s __t " 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.

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

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

------
boomlinde
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!

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

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

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

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

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

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

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

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

------
drderidder
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/)

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

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

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

------
BasDirks
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
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
Great reply, I agree.

------
nsxwolf
"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?

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

------
latenite4
see a great Dilbert cartoon about a similar subject
[http://tinyurl.com/av3ennj](http://tinyurl.com/av3ennj)

------
jwmoz
You can't polish a turd.

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

------
drraoulduke
This article is shi*t

