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

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 just published the source code for the first app I ever built, all the way back in 2003: https://github.com/aaronbrethorst/irooster

It "turns your Mac into a $2,000 alarm clock."

I originally made it because I had endless amounts of trouble waking up for my morning classes in college, and found that the only alarm that could get me up was a subwoofer right underneath my bed. So I hooked a 2.1 speaker system up to my Mac, wrote a little app to start playing an iTunes playlist at a particular time, and ended up productizing it.

It was never a huge commercial success; I think the best I ever did with it was about $2,000 in sales one month after Apple featured it in a newsletter (different times!), but it taught me several important lessons about building a commercial software product that still guide me today.

Enjoy checking out my super janky code!

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.

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.

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.

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

As long as you're learning, old code will make you cringe, though it gets subtler over time.

Though, sometimes things turned out rough because I was too impatient to learn the right way (especially for one-off programs).

My favorite example is when I didn't know how loops worked in PHP, so I wrote an ActionScript program that generated hundreds of lines of PHP instead...

Anyone who judges someone else based on the quality of code they wrote 15 years ago is not somebody whose opinions you should respect.

Honestly, judging anyone else by the quality of the code they have shared is pretty poor form - unless they explicitly say "this code is amazing and you should respect me because of its quality".

My suggestion is to go for it.

With that being said, do take the time to examine the git commit messages and code itself.

I have certainly caught myself from publishing projects that contained words or jokes that would not go over well in 2022 :)

> 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 tend to put anything other there that I consider interesting for others to see, or something that I might want to share with others. For example - ways to to abuse a type system, or how to do something weird like embedding Elm within React. The truth is that if you put out a lot of code, very few people will see any of it, unless you intentionally and directly share with them. If you're applying for a job, chose your favourite repos and send them over. If you want to avoid any form of judgement, just put a disclaimer in the readme. When it comes to games - there will never be enough open source games out there. Being able to see how something done, however hacky, will be great for hobby game programmers.

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.

You should absolutely publish your code if you want to. Do not bother about what others might think about it.

Most people like to pretend they understand Software Engineering and all their code is designed well but that is far from the truth. Real world products are always messy in the first version. It is only when you start rewriting it that it starts getting better (relatively speaking). What counts primarily is that you finished a product/project to requirements and shipped it; everything else comes later.

This is how all learning and development has been done throughout Human history.

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

If it has "artistic" or other redeeming value, go for it. Write a README or blog (or three) covering what's unique or important, or how it fits into some historical narrative. Just be clear with yourself on what you expect to get out of it, and how much work you're willing to put into feeding your pet.

I published something once which was three lines of code. It was useful; anyone could do it, but nobody did (a modem dialing script, of all things). The (often multipage) requests for releases to publish were an unexpected annoyance; I always tried to respond politely that I didn't feel it manifested the requisite originality to be a protected work, and that if they printed the email out and sent it to me with a self-addressed stamped envelope I'd sign it and send it back.

I publish https://github.com/m3047/trualias (checksummed on-the-fly email aliases) even though I consider the code far from perfect: it works, it defines a grammar (which I'm happy with), and it has (pretty comprehensive) tests for that grammar. The most important aspect in my opinion is the grammar and a working proof of concept. (To my bemusement it also has the most stars of any of my projects on GitHub, go figure.)

After enough time passes, all of the code I write becomes embarrassing. I think it's because I'm constantly improving, and all of my historical code was written by a me that wasn't as good as I am now.

The code I write now will eventually be code I'm embarrassed by as well.

This is true for most people, I think, so I don't let it bother me. The effect is a sign of growth.

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!

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

Always share code if you are able. It may be useful or interesting to someone in ways you may not expect.

Also, I don't know if this helps: But I consider myself a bad programmer, and assume everyone writes better code than me. It's probably not universally true, but I also don't feel ashamed of any given work I do: I tell people liberally I'm bad at coding but it works (if it works). It also puts my mindset in a great place to try to learn from everyone else I interact with.

One project I shared not too long ago I announced by describing it as a "crime" against the platform, and almost certainly "a really bad idea".

Just ship your code.

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.

https://github.com/egeozcan/lunchplanner

I was having so much fun back then with this one. Meteor.js was a blast of productivity and I apparently couldn't have cared less about code quality. This is not embarrassing, there's no perfect code and we make different trade-offs all the time, not to mention the skill difference between you and your past self.

Personally, I've put very crummy code out there, and I don't regret it. People generally don't see the code, they see a working product.

At my current place of work, we did a stroll through my github at the interview, I just flat out told "these are terrible, I learnt a lot" and he said "yeah, I saw, but it worked, what would you like to talk about?" and I found one of the more recent projects (still crummy, but you're allowed to write crummy code on your own time!)

I'd be delighted with any attention my code on Github got, good, bad or otherwise.

The only thing that would embarrass me is the number of things I start and never finish.

As far as suggestions for improvement, I'd be happy for any. But I understand the reluctance of the OP. This is a little like my impression of code reviews. That's like standing in front of your coworkers, naked, and asking them to point out any "opportunities for improvement" with your body. I wonder if there is a strategy for code reviews that avoids this.

(HankB on Github (for anyone curious.)

I took the plunge and published some of my old projects over at https://github.com/steelegbr?tab=repositories

Yeah, I'm not proud of the way I wrote the code 17 years ago (historic-alldaydj-1) but it's fascinating looking so far back and comparing it what I'd deliver today. If someone finds use for it, fair play to them.

On that note, I probably ought to dig out the RoTs (tapes) from my days as a radio DJ on a long defunct station...

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.

Go for it! Hell, I threw up some current code on GitHub that's arguably embarrassing (link in profile).

It's not like anybody posting crummy code in answers on stackoverflow is worried about the quality reflecting on them. Or the blog entries that are more or less "I've just learned $technology; now I'm going to tell the world!"

If you've at least got a fully baked project, even if it isn't up to your current standards, you're miles ahead of some of the code people publish.

Take pride in the results. Not the code.

Game development, in particular, is notorious for clever hacks that POKE into registers that elegant code and high-level languages otherwise would not touch.

I've got C++ projects on my website that I wrote when I was 10 years old.

Old code isn't embarassing, it's an unlocked achievement at a given state of progress.

If you feel embarassed by your code you'll never face the harsh reality that time is a limited contigent, and therefore limits the quality of code. Everyone has a trade-off equilibrium when the time spent on a project doesn't justify its workload complexity (or reduction thereof) anymore.

Just do it. Hopefully an employer will read the code and decide not to hire you. (Because it saves you wasting time with a company that does that sort of shit).

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’ve had this thought for some time and only last week did I visit my github page to see what I could do. An idea was to merge all the “beginner” repos into a single repo.

Turns out that recent repos are not to shabby at all and all the other older repos are sort of kinda cute and show that I’ve been having about for some time.

And of course I have private repos for “pro” work.

My advice is to make public some recent serious work and all will be good.

I vote for publishing it. A full product that several people used is an achievement and that the code might embarrass you now shows that you've grown.

I have my earliest programs on 5.25" disks at home which are probably too damaged to read from but which I've never even been able to try since i don't have access to a drive anymore. If i could, I'd put my earliest BASIC programs on GitHub.

You could always license it under something like the CRAPL: https://matt.might.net/articles/crapl/

Publish away. I published all my old source code (that still exists and I legally can), some of it 45 years old. It doesn't matter how embarrassing it is, just say "I've learned a few things along the way" but frankly nobody is going to complain about it.

If someone is rude enough to complain, they are not worth your while.

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

If you can explain what's bad about it and how you've improved since, you never have anything to worry about.

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.

No problem being embarassed, I have stuff published from my high school days (used to carry a 1.44 floppy with MS-DOS 3.3 and TP stuff on it, to get an idea when it was), and university as well.

Headhunters are happy I can check the "I have stuff on github" bullet point, and that is about it.

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.

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.

I think that the fact that you have managed to finish and ship more than 1 game is amazing in itself.

There’s no such thing as bad, embarrassing code. There’s only unreadable and non-performant. Neither of these are that important if the code itself serves a meaningful purpose to others.

There IS such a thing as asshats in our industry who will find any excuse to bully others.

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

Personally, I wouldn't care at all. If it works it isn't embarrassing.

If you're worried about it reflecting poorly on you, make a new github account (asylum-open-source or whatever) and publish under that?

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.

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.

Just throw a line in the README that explains that last paragraph of your post and I think that fixes your problem. We all learn and grow over time :)

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.

If it is bad, then hopefully someone will improve it.

Even if it has "low 4:3 resolution" that is not necessarily a problem; some people might prefer that.

Note that if you publish to GitHub publicly, it will feed into Copilot without any way of opting out.

Yes