Ask HN: Do you have any code currently in production that you're ashamed of?
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?
60 comments
[ 4.1 ms ] story [ 134 ms ] threadYep.
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.
— Maurice Wilkes, Memoirs of a Computer Pioneer, MIT Press, 1985, p. 145And 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?
A different job?
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'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".
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 was making light of the situation a bit, though. I know intent doesn't carry through the Internet, so I apologize.
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.
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.
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:
[edit for formatting.]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.
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.
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.
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...
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.
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.
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.
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.
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 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.
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.
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...
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'm the epithome of analysis paralysis. Being ashamed of my own code is my next milestone. :)