Ask HN: Publish old projects even though the source code embarrasses you by now?

95 points by joemanaco ↗ HN
I have some game projects that were released almost ~15 years ago (https://store.steampowered.com/publisher/asylumsquare/list/100010). Of course, from today's perspective, they have some issues (low 4:3 resolution, for example).

I made the games available for free on Steam because I thought they might still find some players who enjoy them, even if they are of course a bit old-fashioned here and there.

I'm now thinking about releasing the source code as open source. I'd really like to do that, because I think it might be interesting for some people. And if people create new ports or mods/improvements, that would be pretty awesome.

However, from today's perspective, the source code is not very well structured - so it's a bit embarrassing. I'm torn on whether to publish it or not, because it might reflect badly on me as a developer. How would you handle that?

70 comments

[ 2.5 ms ] story [ 127 ms ] thread
Go ahead and publish it. Anyone who thinks less of you now, for the stuff you didn't know a decade ago, is someone whose opinion you're better off not caring about anyway.
I have things out in github that is very embarrassing, so go for it.

But I wonder if putting embarrassing things in github would hurt future job searches ? I very much doubt that since the people doing the hiring will not have any idea what they are looking at :)

I do it, as I like the idea that if one other person finds it useful then it's worth it. I don't put my github on my resume, but my username is my name so it's easy to find and definitely has come up (sometimes indirectly) in interviews. For me, the best interviews have had good discussions about the good, the bad, and the why. From the perspective of trying maximise my desirability to all employers, it has definitely "hurt".
I have a lot of embarrassing stuff on Github and an interviewer has never asked me about any of it. Sometimes they'll ask me to show them my work that I can (is not proprietary from previous employments) and I'll pick a few of the better looking repos to browse thru and provide context. But nowadays I put half my prototypes out there in the open by default so maybe the interviewers just don't go through many of the repos if they do check them out.
One can put a disclaimer in the README to mitigate this saying "I wrote this when I was twelve", then future employers may forgive that your game code isn't optimized for 64 bit multi-core CPUs and your comments don't compare favourably to Fred Brooks' comments (may he Rest In Peace).
Should you be embarrassed by the code you wrote 15 years ago, or proud of the progress you made in those 15 years? It's all a matter of perspective, and you get to shape the type of experience you'll have.
> because it might reflect badly on me as a developer

You don't want to work with someone who would think badly of you for some more than a decade old projects

I'm about to relaunch a 2D MMO title I made in 1999-2001 with new graphics.

It's all in Java and uses MySQL.

Should be fine! :D

Don't know if I would publish the source though, unless it's successful and people want to mod it.

This sounds exciting! Where will this become available to play when you put it online? :)

Also, have a look at Canvas Legacy if you want some inspiration.

Why not publish the source, though?
Because it's 20 years old, but as I said I might do it eventually.

Still torn about open-source, I believe more in source-available + license fee.

The way it works now no single dev. code can be commercially viable except closed source.

Just open source it.

No one will judge you by 15 year old code if you have recently produced good code. That's what people will look at.

Just look at the face palms at Nintendo HQ despite the amazing game they made https://m.youtube.com/watch?v=t_rzYnXEQlE

Try writing books about coding. Now I have to tell people "No! Don't do it that way!"

The right way to make Android apps has changed completely, and the documentation and tutorials are good now.

How about just adding a disclaimer at the top of the readme that the code was written 15 years ago by a much less experienced version of you?

You can add that the statute of limitations for this code has (in your humble opinion) expired, so those wishing to judge you might want to look instead at your more recent projects.

Each of us started out writing shit code. Don’t sweat it. Your ideas and code add to the lexicon, whether it’s written perfectly or not. Publish and don’t look back.
I think that the fact that you have managed to finish and ship more than 1 game is amazing in itself.
After every six months, whatever I had written feels a mess. So it is fine to publish things and improve over time. Or keep the repository private and make it public when you feel like it.

Regarding feedback on your code, receive it as a criticism of your code (and not yourself) and you should be fine.

Go ahead and publish and put your feelings about the quality of the code in the README. Bonus points if you have some thoughts about how you would approach things differently now, if only you had the time.
I have a 10 year old project on Github. I even have it on my resume. The code is nothing like what I would write today, but I think that's implied by it being 10 years old. And I'm personally quite proud of what I produced, even though I would do it differently now.

Project is a WSYIWYG editor (https://github.com/nicoburns/ghostedit) if anyone is interested. I wouldn't recommend anyone use it these days, but it could be interesting as a relatively small codebase to learn from if anyone is interested in how contenteditable in web browsers works.

I think you should publish it, with the perspective that in 10 years from now, you'll be equally embarassed about the code you write today. You're constantly growing - and your code tracks your progress. You should be proud of that.
Context is key here: I would strongly urge you to to create a web page for the games, where you can provide details that a reader won’t get from the source code alone, for example:

* who was the audience/market for this? * what led to some of the technical choices you made? Benefits? Tradeoffs? * what did you learn? What might you do differently today? * What other tradeoffs that affect the code? Time to market? Only an hour a week of dev time?

This code has a story to tell, and only you can tell it.

Fellow HNers: Do you know of good examples of “code stories” that you can share here?

I made an online “museum” of every website I’ve ever made that I could find the source code to: https://jake.museum
Nice memory lane! I like the color combos you use, especially the first site. I've this in the corridor in my house, with flyers and other visual designs I made back in the day. I always look at it and realize I was less skillful then, but still care about the same underlying concepts.

By the way, your RSS feed gives an error. Now I can't get updates from your interesting blog posts.

Oops, looks like there was an invalid character in one of my posts. Should be fixed now — thanks for the kind words and for subscribing! :)
I firmly believe that a finished, running project - no matter how embarrassing the code will not make the person who developed it look bad. Human endeavors are difficult and nothing incredible was made by one person. Additionally, when we make things in groups it isn't one person who's perfect and everyone else is being shaped by that one person. We all learn and grow and help each other learn and grow.

I suggest posting things that make you uncomfortable due to their 'quality' because the more you do it the more you'll start to dissolve that part of your ego that is pre-embarrassed by the imagined responses of people who have yet to review your work. I say this as someone who is struggling to finish a comic written by one of my friends for this very reason.

Do the thing - put it out there (if you have the inclination) - learn - lather - rinse - repeat.

I'd say, go for it!

My most widely-used project (that I was solely responsible for) is an absolute horror of tangled code. It was originally written -- or rather, hacked together with spit and baling wire -- purely for my own use, as a tool to accomplish specific tasks.

Turned out some other people thought it was interesting. I made the code available -- and nearly 2 decades later, it's still going strong, largely thanks to others who have stepped in to handle the occasional maintenance tasks.

The code is still appalling; but it does its job, and people still value it.

Yes, you should do it and others interested in old games and tools that are closed source should try emailing their authors and asking them to consider open source. I've successfully convinced people to open source SEImgTool, an old utility for extracting images from firmware files for old Sony Ericsson feature phones, BFSunpack, a tool to extract game files for the 2006 game Flatout 2 and I think I contributed to open sourcing Dink Smallwood, because I remember asking the author and now it is open source and there is a lively community around it. Still have work ahead of me convincing Sony to open source the above mentioned firmware, whoever owns the rights now to open source Flatout 2 and I could stand Supreme Snowboarding (in the US known as Boarder Zone) being open sourced as well! One can dream. But also, one can act and ask and sometimes it works!
I cannot care less about "embarrassment" when I publish code.

Code is code. Everyone has its own style. Every project has its own constraints.

I guess you didn't write bad code on purpose. You wrote it because it was the best way at the time.

And, frankly, if someone mocks you because of code you wrote somewhere, it's a good sign to ignore them. I don't mean code to be included in some other projects, but code that you wrote for your own eyes.

I’m embarrassed of the code I’ll write tomorrow …

Honestly, no one cares. Add a note at the top of the readme that provides historical context if you must address the point. Otherwise don’t worry cause everything will be alright. People are too self centered to care about your old shorty code.

Any sufficiently large project will have disgusting code at some point. Code that exists (and works) is 100x more beautiful than elegant code that doesn't.
I’ve learned a lot over the years by reviewing old code. It might not be elegant but your methods might spark an idea for someone else.

Sometimes elegant well structured code that is 50 revisions deep doesn’t tell the story anymore

Recently I dug out the source code for a game a friend and myself made in school in 1997. It was amazing to compile it, which it did flawlessly in a DOS/Turbo Pascal emulation. Playing it with my kids was an amazing experience. The code is definitely something I would be embarassed about from a readability/maintenance standpoint today. But on the other hand it can play back video on a 80286 processor :) And I believe everyone understands that you make progress over the years. So I can recommend it, go for it!

My game is available at Github here:

https://github.com/mrichtarsky/K-BOOM