
A Million Lines of Bad Code - var_explained
http://varianceexplained.org/programming/bad-code/
======
swalsh
I recently read the book "How to Win Friends & Influence People", bad title
great book. My main take away from this is I've been talking to people really
badly for the last 27 years. I wish I had read this book in middle school.

But this blog reminded me of some of the concepts from the book, its far more
productive to give positive encouragement than to give negative feedback, and
just adding a complement isn't enough if you follow it with a "but".

"Hey pretty cool program! Its a great start. I bet we can make it run faster
if we changed the way files are imported to something like this... nice work"

will get better results then this

"Hey pretty cool program, but you're reading in files wrong"

which even that is better than this

"You're reading in files completely wrong, try googling for a better solution"
which unfortunately among engineers seems to be the most common reply.

~~~
AceJohnny2
I like teaching. I don't think I'm amazing at it, but I like sharing knowledge
and experience with my friends and co-workers and see them improve, or just
sometimes for the abstract sense of helping. Of course, sometimes I fall flat
and come across as arrogant or condescending, but I hope that's rare. I read
"How to make friends" a long time ago, and I apply those rules diligently to
my interactions with people.

Recently though, I've been assigned a guy to help me with one of my tasks,
managing the build pipeline. This requires a wide range of knowledge about
unix and scripting (Bash, Perl AND Python. Yup. On top of Makefiles, of
course).

The guy doesn't know how to use a command-line.

I'm surprised to find myself to be very unhelpful and curt with this guy. He's
the unlucky recipient of my resentment at the amount of effort I will have to
put in before he can actually become remotely helpful. Of course, it doesn't
help that he's in far off timezone where I'd have to stay up late to help him,
and that I have trouble getting direct answers from him about his knowledge
level. The communication and experience gap is too large.

Anyhow, this is just my two cents relating an experience to show how a
seemingly normal and friendly human being can revert to angry "RTFM"s.

~~~
conistonwater
> _Anyhow, this is just my two cents relating an experience to show how a
> seemingly normal and friendly human being can revert to angry "RTFM"s._

The guy is not just a human being, he's also a professional whose job it is to
know what he's doing. Shouldn't there be some sense of "duty to do a job
well", not just "duty to care about someone's feelings"? If he's not pulling
his weight and is failing at his job, then the poor responses are his fault
also.

~~~
AceJohnny2
Sound like you haven't been working with outsourced talent and a boss that
says "this is all we've got, deal with it." ;)

The "interesting" thing here is the cultural gap, where these folks have had
all initiative beaten out of them throughout their education, where the cost
of failure is higher than that of not trying. It's really disheartening.

My point is, it's heard to blame the person when you know how flawed is the
system they come from.

~~~
capisce
Your boss should pay you handsomely for the extra overtime and responsibility
involved.

------
cubano
If only my clients and recent bosses would consider refactoring a valid
billing line item...

I can only imagine sending an invoice today to my three top clients with "5
Hours Refactoring Bad Code That is Working But Could Be Better
Looking....$400".

There is just no way I would get paid.

Unfortunately, I have interests outside of working on code that mostly
preclude me from sitting for hours happily breaking-and-then-refixing code
that is currently working ok and that I cannot bill on.

Hell, just keeping up to date with the unreal pace of change that is occurring
in software right now is almost a full-time job in itself, much less fixing
old stuff that is going to go away soon anyway.

~~~
gknoy
Would it work to say, "Added test coverage, refactored code to increase future
maintainability"?

~~~
therealwill
Client: "Send us some screen shots of the new features."

You: "Err..."

------
tatterdemalion
> So I wrote a Perl script that read in the file, combined it, and printed it
> out as a single line. Then I had my Java program call the Perl script
> through the command line, capture the printed output, and save that as the
> string.

When I first started (in Python), I didn't understand what a function was, but
I wanted my program to react differently depending on user input, and had some
conception that I should be breaking my program up into files by purpose. So
what I did to get it working was this: I named each file "$cmd.py", then I
concatted the user's input with ".py", opened & read the file with the
associated name, and ran the resulting string through exec() !!

I came to this result incrementally by googling different aspects of the
problem that I didn't know how to describe properly. If someone had been a
jerk to me about it then, I probably would've been really self-conscious about
it. But no one was a jerk, so I'm not ashamed: what I did is ridiculous and
funny & I'm glad to be able to laugh about it now.

~~~
aw3c2
The result was still great though, wasn't it? You made the computer do what
you wanted and it was probably better than doing it by hand.

------
ereyes01
I agree that mean-spirited feedback is not helpful/constructive. I can see how
that would discourage someone who is new to programming. In fact, "feedback"
is probably not even the correct name for that... maybe "bullying".

However, I have to disagree with the notion of having to write a lot of shitty
code to learn to write good code. Granted, that is one way to learn, but not
nearly the most effective way to learn.

For years, when I started my career, I wrote lots of shitty code. I feel badly
about having done this because I unwittingly caused quite a bit of havoc in
the products I was working on, and even pissed off a few customers along the
way. Writing shitty code can have really bad effects on a team and on a
product.

Fortunately for me, I eventually ended up working in an extremely talented
team. They were not only talented at programming, but also highly skilled at
teaching others good programming. Their method was simple- they accepted
nothing that failed to meet their high (and documented) standards of
readability and testing, but were extremely thorough in spending time showing
you what you did wrong. They were never demeaning and always constructive-
they always had a high level optimism in every new-comer's potential. Given
enough time, it was clear that some new team members weren't going to work
out, but those who had it in them to patiently improve their skills flourished
and enjoyed very successful stints with this team.

After a rough first few days on the team, I heeded their warnings and agreed
to check my misplaced ego at the door. Then, and after a couple of months of
embarrassing ineffectiveness, I gradually became a better programmer and went
on to become a great team member. I'm really grateful for the patience these
guys had with me and the other noobs. They really made a difference in my
career and in the career of my peers!

~~~
FLUX-YOU
This kind of thing can really have an effect on your career in the immediate
future. There are a lot of expectations that people come up with regarding
what you should know by X years into your career and people judge you pretty
strongly on this.

I personally don't get any feedback on my code and I don't really have time to
police myself on it. I end up blending in with the conventions I see in
whatever current document I'm working on (e.g. presence of type prefixes,
casing style, underscore usage). I always thought this was bad practice in the
general population but I guess I get paid for it.

We aren't going to raise the industry-wide skill level if we let people figure
it out on their own the hard way. That's valuable up until a point but
eventually they should start wanting to know what the effective way of doing X
is (if it exists). Individuals take a long time to arrive at an optimal point
with that stuff, and may never even reach it.

I'm fairly sure NASA doesn't let staff (astronauts especially) in training
learn everything the hard way. Imagine if your workplace maintained something
like this: [http://llis.nasa.gov/](http://llis.nasa.gov/)

------
JoeAltmaier
Not quite right. All the code I wrote last year looks bad to me; naieve,
clumsy, artless. Because I have learned so much since then. It never gets any
better. Not because I don't get better; because I DO get better.

I've been writing code since 1976.

~~~
losvedir
I hear this sentiment a lot (and notice it in myself, though I have a lot less
experience so it hasn't been as long running), and it worries me.

Are you _sure_ it's better? Are you keenly aware that there are no, say,
cycles in your coding approach?

I know this year I look back at last year's code and go, "oh boy, why'd I do
it that way?" And I _feel_ like it's better, but I'm always a little afraid
I'm just chasing novelty. Not sure how to objectively know if it's better.

~~~
aidenn0
Don't forget also that familiarity makes things seem more clear. Code you
wrote yesterday needs to be particularly atrocious for you to find it hard to
understand. Code you wrote a year or two ago might as well have been written
by a stranger (really memorable hacks aside).

Perhaps look at code from 2 years ago and 3 years ago, and if possible blind
yourself as to which is older, and rate each one.

~~~
JoeAltmaier
I'm pretty sure I remember my code. I agonize over it, put all my effort into
it. I remember code I wrote in the '80\. I remember the code I wrote 7 years
ago, and refactored last year. Code is my life.

I've had that sneaking suspicion that maybe I'm not really getting any better,
yes. But I have independent corroboration - I've worked with another guy for
most of that time, and we've got one anothers' code to look at. What one of us
learns, the other learns too. He's not cycling, or just writing bad code. And
he says the same about me.

------
jackreichert
More important than good code is shipped code.

I'd say about half my bad code is due to inexperience, what the post is
referring to. As time goes on it DOES get better, especially since -- like
most of you -- I'm constantly reading and trying to improve my skills.

The other half of my bad code is due to time constraint. This is either
because a quick hack is needed, or the proper planning time is not allocated
to do a proper job.

This leads me back to my initial statement. Sometimes you just need to get the
job done. If you're not good enough to do it right, but you hack it and it
works, that's good enough for now.

This is how systems get built poorly and bloat up, but there are deadlines and
requirements that need to be met, and if you never ship, you'll never get the
budget to rebuild that old system you allowed to get unwieldy. It's a constant
struggle to balance quality, functionality, and deadlines.

~~~
kgabis
[https://i.imgflip.com/kc24o.jpg](https://i.imgflip.com/kc24o.jpg)

(Sorry for commenting in a form of a meme, but it really was asking for it)

~~~
jackreichert
Very valid point. But not every product, as much as the stakeholder would like
to believe, is a space shuttle.

------
dap
There are some useful ideas here, and public shaming per se probably isn't the
answer. But publicly talking about bad code, and the properties of code that
makes it bad, is an important way to socialize what makes good code, plus the
meta fact that code quality is important.

To the extent that the aphorism about writing bad code is true, I think it's
just another way of saying that people's code improves with their coding
experience. I really don't think you need to write bad code _in order_ to
learn to write good code. It's hard to know for sure, but I think the most
positive influence on my code quality was _reading_ lots of very good code,
not having written bad code. (It's the same with my writing, too.)

[Edited for clarity, ironically.]

------
angersock
I think this is reasonable, but at the same time, _please_ get those million
lines out of your system on somebody else's project.

If that can't be done, if you can't spend your free time honing your
abilities, then accept helpful feedback from other more experienced
developers. Don't just accept feedback--assume your code is garbage, and ask
how you can make it better. If the answer eventually becomes "it's good enough
for business purposes", then find out why that is, and learn from _that_.

Communication is hard, and explaining why a codebase is just wrong can be as
difficult as explaining to somebody why you find them abrasive.

At the same time, it's the job of senior engineers to make the effort and
_try_.

Sadly, in a startup environment, it's usually smarter business-wise in the
short-term just to sack the inexperienced developers or railroad them into
simpler work that they can't screw up, and kick the can down the line.

------
alarge
I'm not a real fan of assigning a context-independent global value label like
"good" or "bad" to code. While there probably are examples of truly "bad in
all respects, in any context" code, the vast majority of code that I've seen
tends to fit more into "<this attribute> of the code could/should probably be
improved when using it in <this context>".

I find that viewing (and discussing) code this way has a lot of benefits:

    
    
        * It is really hard for a single global negative value judgement made about code to not be taken personally by the person who wrote it (e.g., "your code sucks" == "you suck").  This is much easier to avoid when talking about attributes of a thing, since (a) it comes across as more objective than subjective, (b) gives plenty of opportunities for acknowledging aspects of the code that _don't_ suck, and (c) lends itself to much more of a "give and take" discussion.
    
        * It gives you the opportunity to talk about "figures of merit" and trade-offs that are the reality of engineering, but rarely taught in schools (e.g., readability/development cost/flexibility vs.  performance, etc.)
    
        * It gives you a framework for explaining why things like idiomatic style, "principle of least astonishment", and general elegance actually contribute to code quality (and aren't just excuses for subjective attacks).

------
Zelphyr
Code is art and every artist wants to go back and redo their bad works[1]. But
the best thing to do is learn and move on to create better art.

1: [https://www.yahoo.com/movies/bp/steven-spielberg-finally-
adm...](https://www.yahoo.com/movies/bp/steven-spielberg-finally-admits-
walkie-talkies-were-mistake-142746809.html)

------
autoreleasepool
I don't see anything wrong with the "mean-spirited" humor in the XKCD comic.
The cartoon is funny. It's _supposed_ to be a joke. Anyways, it's not like
those remarks are directed at anyone in particular -- just a fictional stick
figure. I don't have any ethical qualms about laughing at his expense.

~~~
chasing
You're right to not have qualms about laughing at something that's literally
just black and white pixels (and some in-between grays) that are arranged in
some configuration on your screen. ;-)

That said, this XKCD comic is one of Randall's rare misses. It's about mocking
something which I -- as a developer -- would actually like to promote: People
taking initiative and teaching themselves to code. Even people who are shitty
at it.

In fact, I'm almost always very impressed with people who are not professional
coders but who have taught themselves a few coding skills in order to solve
some problem or to actualize some idea -- even if the code itself is horrific
from a professional standpoint. That's awesome! And if they want help, I won't
mock -- I'll help! It's a rare opportunity to really show someone why I find
the act of programming to be so fascinating and satisfying.

~~~
autoreleasepool
> _You 're right to not have qualms about laughing at something that's
> literally just black and white pixels (and some in-between grays) that are
> arranged in some configuration on your screen. ;-)_

Not sure what you're trying to say here? Its a cartoon about a stick figure
who can't code. Funniest part was "it's like someone took a transcript of a
couple arguing at ikea and made random edits until it compiled without errors"
lol

> _That said, this XKCD comic is one of Randall 's rare misses. It's about
> mocking something which I -- as a developer -- would actually like to
> promote: People taking initiative and teaching themselves to code. Even
> people who are shitty at it._

I understand that you feel passionately about this, and I agree wholeheartedly
that non professionals should not be mocked. That said, I dont think that's
what's going on here. What we have here, is a _cartoon_ that's poking fun at
an exaggerated circumstance. No individual or group is being (sincerely)
called out or told they shouln't try to learn to code. It's all just a joke,
for amusement.

Its like saying Peanuts is mean spirited for mocking people with poor hygiene
with the character Pig Pen: It discourages those people from leaving their
homes and interacting with people. I should instead encourage those with poor
hygiene to pick up that bar of soap and go outside!

... But that's silly, right?

~~~
chasing
> Not sure what you're trying to say here? Its a cartoon about a stick figure
> who can't code. Funniest part was "it's like someone took a transcript of a
> couple arguing at ikea and made random edits until it compiled without
> errors" lol

I'm just poking a little fun at your earlier reductionism. You're right, it's
just a stick figure. A real human has not been hurt.

My main issue with the comic is that it's not particularly funny. To me. The
zingers don't really zing. It's just someone whaling on someone else for three
panels. And since I'm not catching onto the humor, all I'm left with is the
weird feeling that the comic is condoning that kind of behavior.

~~~
autoreleasepool
You're overthinking a cartoon in attempt to find malice where there is none.
I'm sorry you didnt find it funny, but that doesn't mean it was written to be
anything else but humorous.

There's nothing sinister in this cartoon, no matter what you feel. You might
as well accuse all cartoonists of condoning their characters' outlandish
behaviors. (e.g. "The writers of the Simpsons must condone child abuse because
I didn't find the humor in Homer choking his son" ... Give me a break.)

~~~
chasing
The cartoon was clearly meant to be humorous. The humor fell flat. So the
cartoon just comes off as mean. It's not the end of the world. I'm not going
to attempt to reconcile it with Pig Pen and Homer Simpson in some effort to
create Chasing's Grand Unified Theory of What Is and Is Not Mean-Spirited.

------
kstenerud
I kept some of my original bad C, asm, and REXX code back from my high school
days after I finally moved on from BASIC in 1991. I pull it out from time to
time for a quick chuckle.

------
ianstallings
You have to have thick skin in the programming industry. Because you're
surrounded by what might be the world's worst communicators, programmers. We
can tell the machine exactly what to do, but our social IQs tend to suffer on
the whole.

~~~
Zelphyr
Not to mention we're told from a very early age how smart we are so inevitably
we begin to not only believe it but also believe we're smarter than everyone
else.

Here's a hard-earned lesson for any newly-minted developers out there: Yeah,
you're smart. But not as smart as you think you are. And regardless, it
doesn't give you license to treat anyone poorly.

------
dvirsky
I have here some 10 year old C++ code I've written lying around. It's pretty
terrible style-wise, but not as bad as I imagine it to be without looking at
it.

But the main point is that it worked in production for years. I would have
written it much better today, and it will probably work faster and be easier
to maintain. But it would also probably take longer to develop (though less
time to debug and stabilize) - and ultimately, it would do the same work in
production.

I'm not saying that improving your coding style and skills is not important.
Just that we need to keep our eye on the ball - which is delivering working
software, not code.

------
hnal943
There's a difference between practice and mere repetition. You wouldn't get
any better at speaking Russian if you just spoke gibberish, even if you did it
for 10 years. You need to know what improvement looks like.

------
kctess5
1000000 lines of bad code is a bit of an exaggeration. Many (most?)
programmers never write that much code in their entire careers. I've heard
10000 LOC as a milestone for REALLY learning a language (once you're familiar
with programming in general), I'd say it's on that order of magnitude for
writing non-terrible code in general.

~~~
StillBored
The problem is that a lot depends on what kind of problem your solving, and
whether it varies a lot. I've written ~10k lines of python (single small
project). But, I'm still at the point where it seems every other line requires
me to google something, and i'm sure normal python people would snicker at the
result. OTOH, I've probably written close to 750 (maybe a million, aren't
small companies cool!) lines of C/C++ over the last 20 years and that is
probably not enough either. Although I rarely even have to think about the
code, rather i'm totally working at the algorithm/interaction level and the
text pops out of my fingers.

I would say 10k is enough that you can put it on your resume... But, even that
is probably way less than the average comp-sci graduate writes. So, I would
still consider it a starting point. Especially, since reading other peoples
code is just as important a skill, and that isn't something generally picked
up in school, or on little weekend projects using a new language.

But again, it depends on the breadth of the problems being solved. We hired a
web developer a couple years ago, who in the space of about a year wrote ~150k
lines of PHP and javascript, and got a _LOT_ better at it, but he solved most
of the problems the same way and there was a metric ton of duplicate code, and
imprecise problem solving (AKA problems solved in the most roundabout way).
Over the last 2 years I've probably only written about 50k lines of
PHP/Javascript but I've added about 20x the functionality he added. So, I
would say that i'm better now than he was when he left, but i'm still not
really that good.

------
stuff4ben
I'd hate to see my old VB4 code I wrote back in the day. I'm sure I did worse,
except at the time I thought I was a rock-star. Of course it was the late 90's
and everyone who had a compsci degree was a bad-ass developer no matter what
language you used or how many bad lines of code you wrote.

------
naiyt
I remember reading some advice like this around the time I started
programming. It was something along the lines of "every dev has XXXXX lines of
bad code in them, so write a lot of code to get them done with!". (I think it
was from Joel Spolsky, IIRC.) It helped motivate me to just write a ton of
code, even early on when I didn't really know what I was doing. Just writing a
bunch of code without worrying too much about if it's "right" or not is really
important, at least early on.

I think I write better code now because I spent so much time just writing
stuff early on, and learning from my mistakes. That, along with some good
mentors helped me so much more than the people that merely criticize you
because of your code. I definitely agree with this article.

------
based2
Why not use Findbugs[1] by default, it is now well integrated in major IDEs?

[1] [http://findbugs.sourceforge.net/](http://findbugs.sourceforge.net/) [2]
[http://softwarerecs.stackexchange.com/questions/2902/static-...](http://softwarerecs.stackexchange.com/questions/2902/static-
code-analysis-integrated-with-github) [3] [https://github.com/LMAX-
Exchange/freud](https://github.com/LMAX-Exchange/freud) [4]
[http://spoon.gforge.inria.fr/](http://spoon.gforge.inria.fr/)

------
everyone
The xkcd thing is just one webcomic, I reckon it is just a joke and probably
Randall Munroe did not consider its implications or think it would be taken
seriously. Though xkcd is really popular and probably is relatively
influential (especially in programming circles) That being said, I totally
agree with this article. Also 'read a style guide' is one of the worst
possible suggestions I could think of. Style is just style. Its one of the
least important things I could think of. It depends on your work situation but
in many cases why not just go with whatever style you are happy with
personally and makes sense to you.

------
steakejjs
What if you are an experienced engineer talking to another experienced
engineer ?

Seems to me if someone writes bad code when they SHOULD be writing good code,
code-shaming might be in order.

I'm all for being nice and understanding. Everyone programs at a different
level and I may not write code that is as good as I think, but some code is
just obviously bad...and constructive criticism (if willing to be accepted)
might help

------
serve_yay
Yeah, you shouldn't shame people because their code is bad. But the other side
of that is when someone says your code is bad you don't take it personally.
There is more than one way to not be a nice person.

Just think, if everything is pretty good and isn't _that_ bad and doesn't need
_that_ much improvement, why should anything ever get any better, ever?

------
halosghost
This times a million. I love helping people to learn C, for example. And the
thing I do most other than basic instruction is helping to keep their spirits
up and reminding them that refactoring is the most important part of coding.

------
killertypo
one of my first projects as a consultant fresh out of college was HORRIBLY
coded by my standards today. Sometimes I still fire it up and it still works
(which fills me with pride); however, perusing the code hurts my eyes and I
often wonder what was going through my mind.

------
eduadecastro
Shouldn't the compiler recognize this as an append instead of copying every
time?

~~~
TheLoneWolfling
It should. But the Java compiler punts everything to runtime, and the JVM
doesn't optimize it either.

------
tanglesome
That's all true, but the cartoon is still funny!

------
moron4hire
This is why my handle is "moron4hire". It's supposed to be a daily reminder to
myself that I'm not that hot.

------
eonw
good read, thanks for posting.

------
michaelochurch
Bad code is a great wedge for business people to get programmers obsessed with
individual relative ranking and prevent any sort of collective action.

I certainly had jobs in the past where I got _angry_ over bad code when, in
fact, I should have been bad at the businessmen making me use the bad code
(instead of putting time on the calendar to write things properly) and setting
the deadlines that caused the bad code.

For sure, there are some sloppy, borderline-unethical engineers who write
shitty fast code to get promoted away from the maintenance messes they
generate... and there are definitely some incompetent engineers. For the most
part, though, bad code is a symptom of bad leadership rather than bad
programmers. Under a tight enough deadline, everyone's code will be shit.

And, of course, it goes without saying that the proper response to bad code
isn't to flip out on the person, but to teach him how to do it better. One of
the reasons why I like using high-productivity languages like Haskell rather
than Java is that it selects for people who genuinely want to improve.

------
woliveirajr
Thought his was talking about win95 or win98...

~~~
kenrikm
Windows ME? In all seriousness I've witnessed people shame over bad code, yet
later when other people looked at their code was just was bad. We all write
bad code, hopefully we're able to make it less bad the more we write it.

~~~
woliveirajr
:) think you're the only one that could find the irony out of it!

------
ExpiredLink
> _Building a string with a series of concatenations like this is extremely
> inefficient_

No. Not in Java since 1999 or so.

~~~
Tossrock
Factually incorrect. Creating new strings by concatenation requires
reallocation because Strings are immutable in java. Using a Builder is over
700x faster:

Concat code: [http://pastebin.com/CcezmJbf](http://pastebin.com/CcezmJbf)

Builder code: [http://pastebin.com/Dd6kzcKa](http://pastebin.com/Dd6kzcKa)

Results, using JRE 7:

> time java concat data.blk Finished. java foo data.blk 170.08s user 1.52s
> system 102% cpu 2:48.12 total

> time java builder data.blk Finished. java builder data.blk 0.30s user 0.05s
> system 151% cpu 0.230 total

~~~
Sevzinn
What about the time to write the program?

~~~
Tossrock
About the same.

