Ask HN: Do you have any code currently in production that you're ashamed of? | Hacker News Reader

Ask HN: Do you have any code currently in production that you're ashamed of?

33 pointskrstck58 comments

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 "learned on"? Have you ever written anything that you're sure somebody out there is maintaining and hating your guts?

View on HN

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.

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.

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?

> What would you like if you were to maintain some spagetti VB6 and .NET code?

A different job?

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

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

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

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

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

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

I'm not proud of what I did.

I was making light of the situation a bit, though. I know intent doesn't carry through the Internet, so I apologize.

Yeah, I debated on whether to post the comment or not, but I felt it was an important point to make, and an opportunity to self-reflect on whether you're proud / happy of your work and how to move forward.

I'm also working on a 10+ year old code-base and while I can't always make things "perfect", I always aspire to make things better, and there is no excuse for not documenting (absolutely none, here!), or not writing (unit) tests.

In the future: Documentation is CHEAP! Document your functions at least, there is no excuse, and it is helpful to do "README.txt/DESIGN.txt" style documentation / notes and check it in.

Unit tests can be expensive, but even simply (1 == expected("input1", "input2") || print "FAIL";) is a 100% valid unit test framework in a pinch.

These are very valid techniques to internalize and much better than "but the CTO did it to me first" rationalization.

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.

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

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.

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

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.

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.

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.

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

And if you don't have it you are either not writing enough code, or no longer learning.

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

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

I don't know about that the PET community is still going. Recently they've implemented a Flash drive for the IEEE-488, and emulators are still going. Then again if the programs crashed most folks would just turn of and on the PET and re-load.

looks at what was deployed this morning

Yep.

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.

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.

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

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.

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.

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.

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.

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. :/ )

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.

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

[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

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.

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

I always try to indicate the model in the comments

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.

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

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.

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.

This was the first Rails app I ever built: 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.

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

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.

"One day though"

I say that to myself all the time.

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.

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

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

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.

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.

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.

Oh yeah. I assume everyone does.

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.

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

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

I'm ashamed of half of the code I write

Lots of Forrst

All of it.

always

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.

Reply on news.ycombinator.com