Ask HN: I hate the code in my popular open source app; do I put it on my resume?
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.
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?
Thanks.
60 comments
[ 40.6 ms ] story [ 286 ms ] threadMost 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.
(Sadly, this is not just induction applied to this thread. Not doing the best you can is a key to productivity.)
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)."
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.
It's much better to say "I wrote xxx and hate yyy design feature" than to say "I've never done anything".
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.
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.
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.
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.
love the software, hate the code
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.
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
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.
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.
Man we've come a long way since then.
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.
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.
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.
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.