
Ask HN: Do you have any code currently in production that you're ashamed of? - krstck
For instance, code you wrote when you were a beginner on your first projects. Do you have code out there, running right now, that you &quot;learned on&quot;? Have you ever written anything that you&#x27;re sure somebody out there is maintaining and hating your guts?
======
digitalsushi
Every programmer has a little sewer system buried beneath them. Each morning
it routes digital sewage to and fro, through home built mashers and sprockets
and fittings and tubes and gears. It feels good to see a brand name logo on
some of these devices, a self given high-five for doing it the Right Way, but
invariably there is some lopsided widget bolted to the side with the signature
of self.

It's always shameful to know this little sewer exists beneath us, our
livelihood, our brain babies. To think of all the twists, turns, and dead
ends, unknown waterfalls and geysers yet to be filed away in bug reports, it's
sobering and makes the best of us self-hating.

To peruse other's code, seeing beautiful order, a source code aira, a single
author's master work in symbols... is always the shortest path to shame in our
own designs. Our intimacy with our own creations magnifies our self critique.

Of course I am ashamed of my code. It's the inverse mold of the wrinkly shape
my brain is, and for others to see it is the barest, weakest thing I can
share. One that I am paid to every day.

~~~
michaelmior
Very poetic. I think my satisfaction with the code I write depends largely on
the environment it was produced in. For code I write for myself, I'm generally
fairly pleased at the time I write it. Of course this changes years later when
I look back and wonder what possessed me to construct such a monstrosity.

On the other hand, I find code written for pay is often uglier than I would
like at the outset due to time constraints. But if it gets the job done and
has high likelihood of being scrapped completely (as can often be the case
when experimenting in a startup) then that's a tradeoff I'm willing to live
with.

------
GFischer
Yes, most of it :)

And I'm going to leave a lot more when I switch jobs in the near future.

On the other hand, I had to maintain some awful spagetti code when I was
starting out (and much of that was written by the current CTO!), so what goes
around comes around.

I'd like my successor to hate my guts a little less, but sadly I won't be
around to explain why I made several suboptimal (or flat out wrong) choices -
most were of the "you have one week to implement this" variety, but others
were just me dropping the ball.

When I give my 2 weeks' notice, should I go around all of my old code adding
comments? Documentation? What would you like if you were to maintain some
spagetti VB6 and .NET code?

~~~
ramses0
This is a terrible attitude and I hope I never have the displeasure of working
with you. "What goes around comes around" is a horrible attempt at justifying
doing poor work. Please see the following wikipedia entries:

[http://en.wikipedia.org/wiki/Abuse_defense](http://en.wikipedia.org/wiki/Abuse_defense)

"""it also refers more generally to any attempt by the defense to use a
syndrome or societal condition to deflect responsibility away from the
defendant. Sometimes the concept is referred to as the abuse excuse, in
particular by the critics of the idea that guilty people may use past
victimization to diminish the responsibility for their crimes."""

[http://en.wikipedia.org/wiki/Learned_helplessness](http://en.wikipedia.org/wiki/Learned_helplessness)

"""Learned helplessness is a mental state in which an organism forced to
endure aversive stimuli, or stimuli that are painful or otherwise unpleasant,
becomes unable or unwilling to avoid subsequent encounters with those stimuli,
even if they are escapable, presumably because it has learned that it cannot
control the situation."""

[http://en.wikipedia.org/wiki/Rationalization_(making_excuses...](http://en.wikipedia.org/wiki/Rationalization_\(making_excuses\))

"""In psychology and logic, rationalization (also known as making excuses[1])
is a defense mechanism in which perceived controversial behaviors or feelings
are logically justified and explained in a rational or logical manner in order
to avoid any true explanation, and are made consciously tolerable – or even
admirable and superior – by plausible means."""

Please grow up and learn to do the right thing, or at least make an _attempt_
at doing the right thing instead of rationalizing "there was no other option,
they made me suffer now you suffer, appeal to authority: but the CTO did it".

~~~
kohanz
I don't think it's an attitude that anyone takes pride in. I can very much
relate to the parent. You join a company, find out that their code-base is in
an abysmal state (I would wager this is the case at most enterprise outfits
with aging code) and go to work. Initially, you try to sound the alarm to your
superiors, put in overtime to try and improve the code-base "bit by bit".
However, over time you find out that those who are calling the shots (driven
by business priorities) absolutely do not care, because the code does, more or
less, what they say it will. Your co-workers have either always written poor
quality code or have long-since resigned themselves to doing so. Remember, you
can be in situations where "technical debt" can take months, even years to
culminate into stuff hitting the fan, so management can remain blissfully
unaware of what is brewing for long periods of time.

I've been in these situations before, where your pride for writing good code
is eventually beaten down by your surroundings and the conflicting priorities
of management. I've always been uncomfortable in these situations and found a
way to leave, but I don't think that means that I have a "terrible attitude".

~~~
GFischer
Thank you.

Yes, I work for a subsidiary of a large corporation, the main system is built
on a 20-year old deprecated development environment called Forte 4GL (
[http://en.wikipedia.org/wiki/Forte_4GL](http://en.wikipedia.org/wiki/Forte_4GL)
) with more than a million lines of code.

Technical debt is humungous, but nobody cares since they just put more
programmers to work (it's indescribably inefficient).

I did manage to migrate one of the core subsystems (policy issuance and data
entry) to .NET, and I'm pretty proud of that, but my work wasn't recognized by
management, which spends all the time in politics (and advancement is only a
function of office politics, etc.). Management is pretty short-sighted,
prioritizing short-term shiny new things over fixing problems that will blow
up long term.

So after 5 years I'm leaving, I should have left much earlier but well paying,
stable jobs are not so easy to get in my country, and I didn't want to
emigrate and was afraid of change.

My prediction is that the mismanagement will blow in managements' face when
the next economic crisis hits (currently my country is in an economic bonanza
which masks bad decisions and mismanagement).

------
rprospero
Somewhere out there is the second program I ever wrote professionally. Within
that program is the greatest SQL injection vulnerability of all time. It's not
subtle issue where I forgot to properly sanitize user inputs. Nope, it's a
page that explains in big, bold, friendly letters that any text you type into
the text field will be immediately sent raw to the server for processing. It
might be the world's only self-documenting SQL injection exploit.

I tell myself that the page is only accessible through the administration
interface, which is itself only accessible from the sysadmin's computer and
with a proper password. I remind myself that there is no PII in the database
and that the worst case scenario, if the system is cracked, is that someone
has to count all the desks in the building again. I remember the fact that the
client specifically wanted this feature.

But, mostly, I just console myself with the knowledge that my name isn't in
the source code, so whatever poor bastard is maintaining that monstrosity now
can't track me down.

~~~
Robin_Message
I once wrote a parameter parsing function for a home-grown web framework
(first job, over ten years ago). One of its features was correct handling of
parameter arrays, e.g. foo[42][]=bar&foo[42][]=baz would be converted into
{foo: {42: ["bar", "baz"]}}.

In my naivety (but laudable desire for code reuse and simple
implementation(!)), I parsed the brackets using eval. Without sanitisation.

Parameter parsing using eval. Who would do that?!

Fortunately no-one ever passed foo[42][system("rm -rf .")]=whoops and really
ruined our day...

And the worst thing is, this was only noticed by someone in their job
interview, when we asked them a question based on our production code. They
got the job :)

------
yesimahuman
Yep! Lots of it, actually. The biggest thing you learn is that it really hurts
the ability to extend and grow the feature set of the product over time, but
that if the product never gets off the ground that never becomes a concern.

But by writing and deploying crap code, you also learn how to write it better
the next time. I think most devs know by now how much bad code runs the world.

~~~
teleclimber
I agree on both points.

You definitely need well structured code to make long term maintenance and
development feasible.

But, what is "well-structured" when your app is only in your imagination and
subject to many pivots?

The way I proceed now:

    
    
      1) write crap fast to get it out there and to also 
      discover the potential pitfalls of a given structure
      2) refactor as necessary (it takes off, pivots, performance
      blows, or it's a maintenance nightmare). Be fearless about
      junking entire parts of your old badly designed code if you
      think you are going to maintain this for a while.
      3) see 2)
      4) see 2)
      5) Now that I have a stable structure I keep refining the
      code base knowing that even if it doesn't seem perfect, the
      way I've structured your code is the result of several
      iterations, and is therefore probably as good as it's 
      going to get.
    

[edit for formatting.]

------
kirkthejerk
I wouldn't trust/believe a programmer who isn't ashamed of something they've
done.

In an embedded system, I couldn't think of a nice way to check for the
start+end dates for daylight savings time, so I just hard-coded arrays with 10
years worth of dates.

I was eventually surprised to find out that (A) in 2005 the US changed the DST
dates, and (B) our system actually survived longer than ten years.

~~~
swalsh
I got some code deep in a system somewhere that parsed dates. There are some
limitations to the method, but I figured (and still do) it is pretty low risk.

The comment above that code is // god help us if this line is still being run
80 years from today.

------
weavie
Pretty much all of it and for several reasons. 1, I keep learning new stuff.
2, for it to be in production means there comes a point where I have to stop
refactoring it. So although it could probably be leaner and cleaner, at least
it is in production. The code I do for myself that I want to be really proud
of never ships because there is always something else to do.

------
mattgibson
If you're not ashamed of it, then you've learned nothing since you wrote it.

~~~
kps
I don't agree. ‘Shame’ would require substandard work, indefensible decisions,
incompetence — and I'm pretty sure none of my Commodore PET BASIC programs
survive.

Is there code I would write differently today? Certainly, plenty. That's
nothing to be ashamed of. Time passes; tools change, environments change,
requirements change, and available knowledge changes, including papers
published by people who have explored relevant problems in different ways. Is
there work I would have done differently if not for management constraints? A
little, but that's not for _me_ to be ashamed of. Is everything I've ever done
the best possible under the circumstances? Undoubtedly not. Is that shameful?
No, that's programming.

    
    
      By June 1949 people had begun to realize that it was not so
      easy to get a program right as had at one time appeared. I
      well remember when this realization first came on me with full
      force. The EDSAC was on the top floor of the building and the
      tape-punching and editing equipment one floor below on a
      gallery that ran round the room in which the differential
      analyser was installed. I was trying to get working my first
      non-trivial program, which was one for the numerical
      integration of Airy's differential equation. It was on one of
      my journeys between the EDSAC room and the punching equipment
      that “hesitating at the angles of stairs” the realization came
      over me with full force that a good part of the remainder of
      my life was going to be spent in finding errors in my own
      programs.

— Maurice Wilkes, _Memoirs of a Computer Pioneer_ , MIT Press, 1985, p. 145

~~~
mattgibson
That's fair. 'Shame' is a bit harsh, really. 'Would write differently today'
would be better, but doesn't roll off the tongue as easily :)

------
onion2k
_looks at what was deployed this morning_

Yep.

------
Jallal
As every programmer, I think my skills have improved over the years so yes,
the code I do write now is far better than the one I've written years ago.

I'm not really ashamed, as I do not hear about the "bad" code I've written.
However, when I look behind and assess the quality of code I've been working
on, I sometimes say to myself that my code "was not that bad".

It has been mentionned a couple of times but now, I like to focus my efforts
on code maintainability. I know I'll leave one day or another my current job
and I do not want to be hated like the ones I've hated in the past (or in the
present...) for having written shitty code.

There one another habit I've adopted quite early : when I was writing some bad
code and I knew it, I always tried to let a comment explaining why I chose
this path and what I would have done provided the conditions were different. I
could have written sub-par code due to code consistency with the other parts
of project, to lack of time, sometimes because the implied refactoring would
be to huge to handle in a given timeframe, or because a side effect is likely
not to have been anticipated at first sight, whatever.

At last, the guy who will pass behind me will know my point of view, and even
get some hints of what should be done in an ideal world. And I liked to put
some jokes or funny sentences. Those, I've heard about later after my
contracts.

------
tbrownaw
No.

I have code I would write differently now. I have code I don't like. I have
code that I know doesn't quite work all the time. I have code that I would
have written differently if I had more time.

I _don 't_ have code that I knew was wrong to write the way I wrote it when I
wrote it, given whatever priorities and constraints I was working under.

It probable helps that I don't see my job as writing software. I see my job as
making sure the rest of the team can be as effective as possible, and two
imperfect programs that save 30 minutes each despite crashing occasionally are
better than one perfect program that saves 45 minutes and never crashes.

~~~
krstck
> I don't have code that I knew was wrong to write the way I wrote it when I
> wrote it, given whatever priorities and constraints I was working under.

I didn't intend to ask about code that you knew was wrong at the time. I meant
to ask about code that was the best that you knew how to do, but given what
you know _now_ , makes you feel embarrassed. This is something that I'm
struggling with.

~~~
tbrownaw
No, that doesn't bother me. I'm perfectly happy to say, yes I wrote this, yes
it's crap, this is why it's crap, here are some ideas for fixing it, here's
why I _haven 't_ fixed it.

 _Good judgement comes from experience. Experience comes from bad judgement._

 _God grant me the serenity to accept the things I cannot change, the courage
to change the things I can, and the wisdom to know the difference._

 _The reasonable man adapts himself to the world. The unreasonable man adapts
the world to himself. Therefore all progress depends on the unreasonable man._

Much of programming can be viewed as adapting the world. It's not reasonable.
It requires experience. Gaining experience will _inevitably_ show that what
you've done in the past could have been done better. You can't change what was
done, so don't bother worrying about it. You can _learn_ from what you did,
but recognizing the problems is how you _know_ you've learned, how you know
you've improved your judgement. This is a _good_ thing. Don't try to hide it.
So you didn't spring into existence already knowing perfectly how to adapt the
world? So what? You're not supposed to.

------
buckbova
No, I wouldn't say ashamed.

When I first started out, I would not let there be something I didn't have
some knowledge about. So, after work I'd go home and study or work until I
understood everything I could about my position. For me this was classic asp,
cold fusion, sql server, db2, informix, perl, and other technologies for CRUD
applications, reporting and data management.

I always tell all the developers I work with, If everything you put into
production is "well thought out" and has reasoning behind your decisions, then
I don't mind if it is not the design pattern I would choose, or uses the exact
style I prefer.

------
Ronsenshi
You bet. My early code sandboxes are horrendous to look at and probably
headache-inducing for anyone who might try to decipher them.

I remember one small PHP-based random avatar generator I wrote several years
ago. Even at the time of writing I understood how horrible it was. Nowadays
I'm afraid I'll have a stroke just by looking at it.

But those were the past days. Nowadays i know better thanks to some great
people out there with smart things like SOLID, OOP etc... . I wonder what i'll
think of my current code in a year. Most likely will be embarrassed by some of
it anyway - there's always a better way to write something.

------
seivan
A ton. None of it is owned by me though. My own code, that I own (open sourced
mostly) is actually well tested and amazing.

That's because I can take my own time and sit down for four hours and just
think of stuff like naming functions or selectors.

I could spend time on Twitter and/or IRC and ask people about gists of code
and their opinion of it. Imagine it being user testing, but code base.
Basically reviews.

I would be able to go back and just rewrite it for the sake of naming sakes.

No employer would ever approve of that.

That's why my own code is always going to be better than the one I am paid
for. No one wants to pay for that.

------
wwweston
I work for an agency whose clients include big 5 automakers. Since last April
I've been assigned to do maintenance and feature requests on a JS-heavy
mobile/tablet build-and-price web app for one auto manufacturer.

The codebase itself seems to originate in 2009; there's some kinds of
controllers, but no consistent model to speak of (just lots of service calls,
with JSON/data markup stored in and retrieved from the DOM). It has its own
not-jQuery DOM manipulation function(s) which, of course, are more poorly
conceived and missing significant chunks of the utility of jQuery, and the
codebase largely never rises to a level of abstraction above DOM manipulation.

Because bad code is a bit like abuse -- there's a cycle of transmission -- I
tend to write pretty bad code for this project. If nothing else, even when I'm
writing good-ish code I'm still writing at the DOM manipulation level, which
isn't so good. And that's the high point I can aspire to without taking on a
significant rewrite (assuming anybody would pay for it).

So, day to day, when I'm not reading terrible code, I'm writing it. Good
times.

(Also: not to say that I've never written terrible greenfield code... I have,
and some of my never-show-this-to-anyone newbie C code may still be in
production as part of an not super popular but nevertheless enduring
e-commerce product. Sometimes you start the cycle. :/ )

------
ChikkaChiChi
There are two types of emotions I can feel when opening code greater than a
year old:

1\. I get excited because I look at my shit code and realize how much better
I've gotten SINCE I wrote this piece of dog turd.

2\. I get excited because "Past Me" was clear, documented well, added
something that I wasn't expecting, and did an all around fantastic job when I
wrote it. Past Me was fucking awesome.

The point is that I'm never ashamed. I'm learning.

------
ghh
Yes! Please refer to the image at [1]. It's also on the cover of the
introduction of 'Clean Code' [2]. Everyone here has some code that they are
not proud of. You should see it as a sign that you've learned from the
experience of designing and developing it.

Want to steadily improve on non-production code? Try codewars.com: you're
asked to solve 5-30min coding exercises and after can immediately browse the
solutions of your peers. The short feedback loop helps you understand how you
could've improved while the code is still fresh in your head.

[1]
[http://www.osnews.com/story/19266/WTFs_m](http://www.osnews.com/story/19266/WTFs_m)

[2] [http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsman...](http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882)

------
nswanberg
I have code in production that I wouldn't be happy to have to share. I have
some that I'm a little proud of. But none of that matters compared to my
feelings about whether it's useful and usable. I'm still working on making
something I can be proud of in that way.

A few weeks ago someone posted about what it's like to work on the Wolfram
Alpha codebase, and described it as a pile of mud. I've read that parts of the
Google search codebase could use some rewrites (and a long time ago someone
converted it from Larry or Sergey's crappy java code to some nicer python).
But noone but the people working on them see that, and while some folks who
come and go might mutter under their breath as they sort through what some
code might be doing, their opinions pale in comparison to that of the people
using those systems every day.

------
artificialidiot
All of it. Right now I am looking at an SQL&perl mutant I wrote and wondering
what I was smoking at the time.

~~~
yread
I always try to indicate the model in the comments

------
emhart
Oh yes, I'm actually in the middle of cleaning up a huge chunk of it. Managed
to strip 1200 LOC yesterday, going for another 1k at least today. Then a long
series of commits, a new deployment and the next time I, or anyone else, has
to look at this, I won't feel quite as guilty.

That said? It is an incredibly rare luxury in my career thus far, to get these
sorts of organizational breaks. I recently checked the code of the first
website I ever built - I was learning on the job and asked to convert our
flash only website to HTML/CSS.

To my horror, every line of my code was still in place. Every dumb mistake,
every awkwardly shoved pixel, every dubious form. Everything. I actually found
a couple potentially serious bugs & emailed my former employer to report them.
Bleh.

------
dm2
I don't think I have any ugly code but I have built insecure apps and sites
before. I've asked myself "what if someone does X, could they steal data?"
numerous times after a project is out of my hands.

Similar question: How much damage could you do (or data could be stolen) by
hacking sites / apps that you built in the past?

My former boss, who was also a software developer, frequently told me that
moving to the next project was more important than doing a thorough security
audit of large public sites we built. It wasn't my company on the line, so I
had no choice.

Also, many of the projects I've built have been proof-of-concepts in my mind
that have been rushed into production. Those projects have likely not scaled
too well...

------
krapp
[https://github.com/kennethrapp/phasher](https://github.com/kennethrapp/phasher)

At least one person is possibly using this in production to match images in a
catalog. He contacted me about its tendencies to give false positives (because
it's optimized for speed and not necessarily accuracy) and I had to admit that
I literally do not understand the math or image algorithms well enough to make
it do what he wanted.\

Also most of the code I get paid for is javascript hacks for Business Catalyst
sites, which are usually ugly, wicked little monsters whose only redeeming
quality is they _work_.

------
wnesensohn
I have only written very few pieces of code which I'm not ashamed of right
now. A few functions here and there which make me smile when I read them.

But despite that I have the feeling that I usually improve the code I touch. I
don't know if that's a good thing, as it means that I usually learn from
mistakes I had to make by myself, but at least it's learning, right?

I try to minimize the amount of code I write and don't actually learn on. If
that code should become the majority I know that I'm doing it wrong.

I'm coding for only 15 years now (10 years full-time), but I hope that I'll
never stop to be ashamed of my code.

------
danso
This was the first Rails app I ever built:
[http://projects.propublica.org/bailout/](http://projects.propublica.org/bailout/)

It looks great due to my colleagues actually applying good design principles
to it, but the backend is definitely horrible, thanks to me. A contractor
helped me with the admin interface but when I left, instead of paginating
through the many data entries, it just loads everything up, resulting in a 1
minute delay for any data entry/updating/listing action. I think that was all
overhauled by much better devs after I moved on.

------
mschuster91
Not code, but a 2-years-not-upgraded public facing web server.

------
jbrooksuk
Yeah, a lot of my code that's not a personal project.

I had a lot of code left in my hands when I started the company I'm at, it was
awful, and unfortunately I've not got the time to go through and rework it
yet. One day though. So everything up until now has just been bolted on and it
comes back to bite me at least once a month.

I've started using Laravel now and I feel much more comfortable knowing that
it's keeping me on the straight and narrow.

~~~
emhart
"One day though"

I say that to myself all the time.

------
implicit_none
Yes.

My first big web application has absolutely no unit tests. None. Why? Well,
when I first learned to code I was taking the Udacity cs253 course, in which
there was no instruction on unittesting in Python, so several of my projects
shortly thereafter contained no unittesting. I was actually quite proud of
these projects until my brother asked if I had any tests ... "what is a test?"
... his face was priceless.

------
bonobo
Lately the only thing I've been feeling ashamed of is the amount of code I
DIDN'T write. I think this is mostly because I fear feeling ashamed of my code
after it's running or, even worse, after it's public. I don't know...

I'm the epithome of analysis paralysis. Being ashamed of my own code is my
next milestone. :)

------
at_kjellski
Yes, actually the better part of the system I'm working on right now. My very
own code looks extremely bad to me since I'm continuously learning. Isn't that
a normal part of trying to get better? I wrote some really evil stuff already,
but I try to get better at least...

------
jonalmeida
I worked on some mobile UI stuff which had a couple alignment issues which I
didn't get to fix before I left. Now that it's in production, that's all I see
as an end user of my own product.

It's nothing disastrous, but seeing it there all the time kills me a little
everyday.

------
foz
I find that by calling it "legacy code", it helps to feel less ashamed. In
general, I would be worried if I did NOT have production code that I felt
could be simpler, faster, or more stable. Maybe just a side-effect of becoming
a better developer.

------
joesmo
I'm not only ashamed of it, I apologized to the programmers that had to come
after and maintain it. Regardless, I don't regret it--it helped me get where I
am and ironically, it works well and is quite fast. Too bad no one can figure
it out.

------
Glyptodon
Oh yeah. I assume everyone does.

------
nobodysfool
I try to post my shameful code to github in the hopes that I'll do my best
with every new project I start. I've only just started it, but it's helped
with my thinking process.

------
theshadowmonkey
Yep. But that was done on a time crunch or had to get it done times. So, I
make note of things as I write such code wishing to fix them one day :D

------
duiker101
I can imagine this thread become pretty long... btw definitely.

------
wnevets
I'm ashamed of half of the code I write

------
mikelbring
Lots of Forrst

------
27182818284
All of it.

------
stigi
always

------
benched
All the code I've written at my current job is deployed to an audience of
something like 35 million. As of now, I haven't been made aware of any bugs
reported against it. It's formatted nicely. Things are named well. I dunno.
How should I best try to fit in with the predictable _mea culpa_ torrent this
thread is sure to become? Oh, I must not be learning anything. That's the
accompanying natural law, right?

My point: It doesn't make sense to say "of _course_ my code is shit" unless
you also have in mind parameters for what would make 'good' code. My standard
is simple at this stage: Does it work and not annoy users? Can my team read
it? Then I'm not giving it further thought, positive or negative.

