Of course you put it in there!

Try something like "Created X-PHP app in 2001. With one million downloads, X-PHP powers [large_number] sites as tracked by netcraft. (link here)"

You can't leave something like that out, it's an impressive accomplishment and ignoring it due to some PHP sensitivity is a bad idea.

The one and only purpose of a resume is to catch the eye of a reviewer and thus score you an interview. Once they see that you've published a 1M-download app and call you in for an interview then you can tell them what you've learned in the past ten years.

Think of it in terms of conversion rates. Some small percentage of resume readers are going to request an interview. Some smaller percentage of those are going to make an offer. You don't want to self-select your way out of that first pool.

Edit: I have old projects on my github that are ugly too. I put my misgivings in the readme. "This was written 5 years ago, it could stand to be modernized, the interesting parts are here (link)."

> The one and only purpose of a resume is to catch the eye of a reviewer and thus score you an interview.

This is extremely true, and yet it's amazing how many people don't know / don't want to hear that. Most people seem to think a resume is "them" put on paper, so it should be so thorough it should list every activity they ever attempted from kindergarten on (except the ones they are now kind of ashamed of, ten years later).

Your resume is not you. It's a tease.

Yes.

I interviewed and eventually hired the developer of a name-brand open source project years ago. I asked him about parts of the code, and after I hired him he confessed that he thought it was game over right at that moment of the interview: he was embarrassed about the PHP he'd written.

I didn't care a bit. He was a fantastic engineer, he recognized what he no longer liked about his old code, and most importantly he created and shipped a huge, popular project. Very few people can say that.

Claim it, be proud of it, and be prepared to talk about the mistakes you made.

That engineer, by the way, has now been at Google for years. He's doing just fine.

One thing college has taught me, all though not neccesarily for the right reasons (there's overemphasis), is that you can fail: just be able to reflect on why and what you would do differently next time. I think being able to say you shipped and being able to tell what should be changed, updated or improved attests to your skills.

You are supposed to hate your code.

If you don't hate it, you aren't trying hard enough.

I would not equate hating the code with the code being something to be ashamed of.

I hate every goddamn piece of code I write.

I'm always biased against my code as well. But man.. Software with a million downloads is something to be proud of. That's a lot of people getting use out of something you created.

One of my uni professors had a good maxim he has posted above his desk:

love the software, hate the code

I thought it was only me. But I periodically go back and stare at how beautiful some of my code is too.

I seem to have a 3 year window during which I hate the code and then I come back and think, "wow, that's pretty nice code, why don't I do code like that any more?". I think I spend a lot of time obsessing over small warts and it takes time for those to recede into the background where they belong.

I hate my code but usually I hate other's code even more. What makes me think my code is not so horrible is when two days after my commit I check commits from my teams on it, and I see their updates nicely integrating the logic I built, proving they understood easily how it is working.

The more I code, the more I do it for other people getting behind, and also the more I "flatten" the code. By that I mean:

- Remove recursions

- Remove pretty hacks

- Split dense logic (one line = one thing)

- Replace comments by properly named function calls

- Factorize everything that is happening more than thrice

- Linearize sequences of steps

- Remove nice to have just in case, but never used function parameters

- etc.

Nobody has ever written perfect code. So don't worry about it; writing code and being able look at it critically are both rare skills, and will look great in an interview.

It's much better to say "I wrote xxx and hate yyy design feature" than to say "I've never done anything".

There is a difference between perfect code, nasty code, and ok code. It doesn't take much to turn a nasty patch into an ok one. Around 2002 or so I realized that all of my open source code could one day be read by someone looking to hire me. It really made me change my coding style. Taking the extra thirty seconds to review your change, make a better commit message, follow a common code style, better variable and function names, make a README (back before github) etc. The more I did this the more I benefited from it myself. I caught mistakes, it was easier to go back in the history of commits etc. In essence I became a better developer for it.

tldr; Always assume someone will be reading your code in the future for a job hire. If not for them, for you as it will make your code better.

> tldr; Always assume someone will be reading your code in the future for a job hire.

I agree that what you suggest in terms of improvements in how you code is beneficial--especially if it's a permanent change in your coding style. I think permanent changes in coding style like that happen when we realise it's actually beneficial to us even before it helps someone else.

At the same time I posit that there is much useful/functional (albeit ugly) code sitting trapped on hard-drives around the world because the developer is concerned a future employer/client might judge them for it if it were released.

While this sort of filtering by prospective employer/client may well happen, I think the average developer concerned about such things has a much higher standard for work than needed.

I've tried to adjust my thinking to "Well, it works for me, that means it might be useful to someone else, so I'll put it up there. If some future employer/client can't see that it's a quick hack and not representative of my daily work, well, that probably says more about them."

I'd rather find your 10-line hack to get that obscure API working and build on it, than nothing at all.

Agreed. It is more useful in the end to just push our your code even if you add a "warning: this is one big ugly hack" as a readme.

in my opinion it should be tldr; Always assume someone will be reading your code Wether it's a potential employer or an open source contributor, those are always good practices.

Uh, what? Forget about potential employers or open source contributors. You will be spending a lot more time reading your code than you'll spend writing it. So making things readable makes things easy for you.

As the creator of MagpieRSS I know exactly what you're talking about.

And yes, you include it. There are skills demonstrated in a popular open source project which are interesting and relevant, and very very few people are proud of the code they wrote in 2001, no matter who they are or what they do.

You wrote that! I used that when I first started doing web development to show posts from certain categories in wordpress before that feature made it into the core.

Man we've come a long way since then.

I used MagpieRSS in mefeedia.com, thanks for that :) Just think, it may have been dodgy, but my own code would have been much dodgier, so don't feel too bad :)

Kudos, love the software. :)

Agree with people here. Absolutely yes.

True Story: I was in the same boat. Usually people have never used it, but google for it to verify it's real - and are suitably impressed.

However, one day I interviewed at a company who had not only heard of it, but actually used it in production! I couldn't help but blurt out "Really? The code is horrible isn't it." - This turned the tide of the interview, as it showed the interviewers I had the ability to objectively review code and learn from my mistakes.

I was hired, but had to suffer being the butt of all jokes for a long time.

I definitely agree with the comments here. I don't know one good developer who doesn't want to rewrite 50% of what they previously written. That rate always goes up to about %100 if it's written when they were anywhere near new to a language.

The fact that you belted something out that was useful and stable enough to still be active is a testament to your intelligence - and that is what a good potential hire employer is looking for.

BTW, you looking for a job in Durham? http://argylesocial.com/jobs/durham-nc-software-engineering-...

/adam

Hell yeah!

If you are lucky they might even ask you about it in an interview, and then you'll get a chance to explain how & why you'd do things differently.

More likely, though, they'll see the name of it and go oh, I've heard of that - it seems to be used a bit so it can't be total crap and put you in the "interview this person" pile.

Everything you wrote more than six months ago is crap, or should be. If it isn't you've stopped growing as a developer.

Anyone looking to hire you either grasps this, or isn't a sound enough developer to see past the popularity of the package. Either way you win.

Have to ask: what's the app? If it something thats not only popular buy well thought of -- well, you can always mention in an interview how you're unhappy with it and how you'd improve it today.

Most programmers - myself included - look at things we did last year, two years ago, etc and think "how awful is this?". I've yet to meet someone who doesn't.

I'm usually questioning the code I wrote 15 minutes ago.

Eventually you will be able to regret the quality of the code before you have even written it!

(Sadly, this is not just induction applied to this thread. Not doing the best you can is a key to productivity.)

True! The real problem there is, if you regret it enough before you write it, you might talk yourself out of writing it to begin with...

The best code is no code?? ;)

The less code you have to write, the less there is for you to slowly start to loathe having around.

Procrastination, anyone? :) I sometimes have to force myself to write it down at all.

Definitely include it.

If a relatively non-techie person is reading your CV (i.e. if HR is doing pre-screening before passing select ones up the chain for consideration) they won't know to check the code quality, they'll just see that you were important for a significant project which proves you can handle yourself well technically.

If a techie person is looking at your CV, they will understand that a lot of code, especially code that is written in your own time so you don't have to go back and resolve QA issues, is far from ideal. If the project was popular, technically impressive, original, interesting, or any combination of the above if will be an advantage to you. A technical interviewer will probably bring it up in the interview, if they do you will be able to sell the good parts of it (and why they mean you'll be good in the position you are interviewing for) and discuss what you would do differently if you were starting now and why (which will give the interviewer a gauge of your ability to appreciate and learn from experience). Recognising a problem and how it can be addressed is more valuable in judging your real world (i.e. imperfect world) abilities than just talking about things that are right.

Disliking parts of your old code is normal. If you look back at your code from a few years ago and don't find things that make you cringe then either you were a savant, very lucky and "on form", had a lot of time to work on it which allowed for regular refactoring as the codebase grew, or (and this would be the worrying one) you just haven't learnt much in the intervening time.

Definitely put it on.

In a backhanded way there is actually value that you can work effectively with "bad" code. Many places that are hiring are hiding their own shameful secret : they hate their own code. Sometimes something they are even screening for is to make sure the person is not going to baulk when they discover the reality of the code they are now involved in and who will be pragmatic enough to work with it try and make it better rather than declare it's a disaster and not their fault.

Wow, I have an incredibly similar experience. I made a PHP news script called "CzarNews" back in 2003 that was widely downloaded and used, and is still used on many sites today.

I too am now a bit embarrassed by the amateurish-ness of the code, and the security vulnerabilities within it. Previous versions of it back when I was actively working on it even hit Secuina security advisory lists under "high" and "severe" categories and led to my server getting hacked through a remote file include vulnerability (thanks PHP3/4 register_globals + allow_url_include INI settings on by default!). I learned a lot about PHP (in)security that summer, and had many angry users to deal with. Your experience surely can't be worse than that.

In addition, I too have NOT put the code on my GitHub account, because it's nothing like the code I produce today, and I don't want people to get the wrong idea about what kind of code I produce. I have never thought about just owning it and wearing it as some sort of badge of honor though - this thread has made me re-think that. It might be interesting to highlight its success and the lessons I learned through the process.

I have been thinking about something similar. I'm shutting down my first startup (circa 2007) in 3 months and thinking about open sourcing the code. Several have asked me about that. Thing is it was my first Rails app and one of my earlier attempts on working on a large web app.. so I'm not exactly proud of my code either..

I would say yes, especially if you have newer code you can show off as well. Code can always be refactored and improved, but knowing (and making) what users want isn't something they teach in school!

If I were to compare myself to how I am now to years ago I would be ashamed of the code I wrote.

Occasionally I have to dig out legacy projects in php and wonder how my code was ever scalable. My main thing was bad class decisions, naming and what to put in them.

If the code I had written had been downloaded a million times though, I think my view would be different, I would be proud of it. It doesn't get downloaded for no reason.

The only thing that matter is, if you had the chance to rewrite the code, would you know what to do differently? I think that's the real angle you should be going into an interview with. You have an app with a million downloads and if you were to do it all again then you would do X differently.

I don't know if you are referring to OsCommerce but I can tell you that is some pretty bad code in there but for the best part of 3 years I would use it on sites all the time. It doesn't make the idea any less brilliant.

Good luck

Yes. Real code that actually works in the real world, for large numbers of users, on all sorts of weird platforms and configurations, tends to accumulate some cruft. I'm sure there exist beautiful, production code bases that have been downloaded and/or used millions of times, but there's no shame in some ugly code.

I seem to remember an old piece by jwz talking about the "clean-up rewrite of Netscape" and how the poor folks who were doing it then had to re-fix and re-workaround all of the myrid ways that broken old versions of ftp servers implement the protocol. It was probably ugly code, but it worked, and the clean code only stayed that way until it met the enemy...

This, my friend is your experience. Make the best with it. To be honest, it sounds terrific.

Also, some years ago I wrote an accounting application I wasn't particularly proud of and it was always with apprehension that I was going back to it to fix some minor bugs. Overall, it worked quite well though.

One day a coworker-friend IMed me to let me know that he had fixed a glimpse in it and said he was impressed at how lean the code was in it and how, ... You get the idea.

So two things: you will always hate your code because it's your creation, thus not/never perfect enough, and you will often find worse coders than you to provide some sort of relief :)

I also released an open source PHP project in 2001 (http://templation.websaviour.com/). It got zero uptake, but it's still used to power a few large sites to this day. The fact that it never got any use meant the codebase stayed lean and the ideas pure. I can think back on it with fondness and believe that even now, 10 years on as a professional web developer, I had great ideas from the start.

Of course it's not very impressive on a CV if no one uses it and no one's ever heard of it, so on balance I'd have to choose your predicament. Congratulations!

Besides agreeing with most of the comments here: for me, the demonstrable progress in your work would be more important than the past or current quality of your code.

If it has been used by millions users, it cannot be bad code on every front. For example, maybe the architecture sucks, etc... but this came after you already had many users, so you could not change it easily: that's inherent to most projects out there, and the ability to deal with it is one of the most valuable skill you could look for in a prospect hire.

Are you saying,you didn't learn a single thing with that project? If you learned something out of it (whether its design part or coding part) you must add it to your resume. You can tell interviewers you didn't follow any coding standards with that project. But now you are started to follow them. Open source project always add more value :D

That's what asterisks are for. You learned a lot from it, and it was popular; that's why you include it. You can acknowledge that its a steamy pile of shit and incidentally show that you've grown as a developer and are able to acknowledge your past mistakes. Those are the traits that will make you stand out from other candidates.

Absolutely, you should -- for everything already said here, and more. When you interview with a company do they ask you about the project? Have their developers looked at the code in enough detail to question the design decision you've made and see what you've learned since then?

I agree with all the comments, but one question remains: would the interviewer think like we do? You could argue that you shouldn't want to work there in such a case, but the interviewer may not be representative of your direct colleagues. How large would that risk be?

Familiarity breeds contempt. Everyone hates what they wrote a few years ago, as it represents the person and place they were, and they've done so much improving in the interim.

Keep it on your resumé - for all the reasons everyone else has posted.

I would say something along the lines of what you said here. You were new, there are a few things you'd have done differently now (and list what those are) but that people love it and its not your primary interest anymore, etc.

If I were hiring, I'd look at your ability to organize people and generate interest in what you do, and your ability to make something that others find useful.

Make sure you include sample code that shows your recent good code. If they think all your code looks like that it's going to be a big negative.

Definitely. I'd put it on and add some info about what you've learned since. It must have grown you in immeasurable ways, so why hide that?

If you hate the code that much and you've been working on it for 9 years, why haven't you gone back and "fixed" the ugly broken bits?

Yes, put it. At the end of the day , everybody hates the code (that's the earned maturity/knowledge)

You're the one that wrote PHPBulletinBoard??? :)

Yes, you put it on, and say 2001-2008 on it.

Yes. Experience, even with crap, is useful.

If you put it on GitHub, wouldn't it create the impression that you had recently written it, due to the timestamps?

If I were you, I'd milk that app's notoriety for all it's worth, though I might not make it too easy for people to find the code. Oh, and don't be ashamed of your baby. Even ugly babies are worthy of bragging if they're popular.

The commits will have the actual timestamps if he preserved history.

Hey Everyone - did you know that I once single-handedly saved 1.6 million kitties from a forest fire?

Yeah, well I did. Cool, I know. But hey, I like puppies better than kitties. Should I mention my amazing feat on this application to the NYC Fire Department?

Do you think the NYC FD will even care I saved 1.6 million kitties? Saving turtles is WAY cooler right now, sort of like node.js., I wouldn't want anyone to know that I was even good at saving kitties.

Thx, Grant