
Ask HN: I hate the code in my popular open source app; do I put it on my resume? - rsp
From 2001 to 2008, I was the creator and frequently only developer on a relatively popular open source project. It was one of the first pieces of real software I'd written, and was the first thing I ever released as open source.  It's been downloaded about a million times and is still running on many sites today.<p>The thing is I really, really hate the code, and it's in PHP (these are only partly related). There are parts of it I'm downright ashamed of. My question is, should I put it on my resume and/or my GitHub account? Even if I'm applying for a software job that won't be using PHP?<p>Thanks.
======
dpritchett
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)."

~~~
bambax
> _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.

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

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

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

~~~
3dFlatLander
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.

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

 _love the software, hate the code_

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

~~~
icefox
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._

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

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

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

~~~
wh-uws
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.

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

------
covati
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-...](http://argylesocial.com/jobs/durham-nc-software-
engineering-job)

/adam

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

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

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

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

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

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

~~~
mishmash
The best code is no code?? ;)

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

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

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

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

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

------
jarin
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!

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

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

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

------
dasil003
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!

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

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

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

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

------
jonburs
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?

------
Confusion
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?

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

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

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

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

------
richardw
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?

------
Kaizyn
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?

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

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

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

------
jhuni
Yes. Experience, even with crap, is useful.

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

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

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

