Hacker News Reader

Comment by pierrefar | Hacker News Reader

The downside is when someone finds code you haven't touched in 10 years and would disavow now and think it's your current standard.

So make sure you keep the home pages of such projects updated by saying "this project has been dormant since...".

View on HN

The "problem" with old code is the same as the "problem" with old blog posts. Sturgeon's Revelation applies: 90% of anything is crap.

I trust that someone surfing the net for words I've written is aware that some are better than others. Likewise, I trust that someone surfing Github for code I've written has the same expectation that most of it will not be my best work.

Curating your work is not "free." In addition to the time cost, if I was worried about people assuming I'm a bozo after looking at my work I would probably avoid posting the things I've written that were failures like the Ick gem in Ruby.

That in turn might avoid being rejected sight unseen but it would also eliminate the possibility that someone would ask me, "So, Ick looks like a crap idea. What were you thinking? If you agree it's crap, what have you learned?"

I actually keep some crusty old code on github intentionally. Since github sorts your profile page based on last commit, it shows up near the bottom of the list anyways. By having gross old code, I can show how much I have improved and advanced myself.

Looking at code that I wrote a few years ago (like when I was first learning OO and Python) and comparing it to more recent projects is like night and day. It helps me to not feel so inferior on those days when I read too much HN and get too hard on myself -- and I would think that an employer would be interested in seeing growth and improvement.

What would you say are the most important differences between your bad, old code and the way you code currently?

Following conventions/best-practices. Not duplicating code unnecessarily. Using features of the language to my advantage instead of forcing the language to fit my program structure.

And also just an overall improvement in the quality of the code - less room for bugs, less 'hacky fixes', easier to maintain/extend/modify

Most recent commit date? Such things really speak for themselves.

Good point. You're assuming that 10 years ago you released software properly instead of just zipping up some PHP scripts and offering that for download.

You're also assuming that the person who's reviewing that old project code will dig deep enough to see how old the commit dates are. I think the GGP's advice about updating the project page is a better bet than relying on the reviewer to pick up on more subtle hints.

If the reviewer doesn't know enough about source control to fairly quickly find the most recent activity date, is it likely said reviewer is competent enough to review the source code itself, or even spend time reviewing it in the first place?

The fact that the reviewer has the technical ability to do something on your behalf does not mean he will. Specially in a weak labor market, the reviewer's job is, more likely than not, find a reason not-to-hire this particular candidate and pick the next resume on the stack.

On the other hand, think of a candidate that is able to identify a relevant piece of information, and willing to do a little extra work to display this info where the people who need it can easily find it. In my opinion, this is a sign of strong soft skills and general common sense.

Ok, fine, but if it's his job to quickly slough off imperfect candidates using minutia and minor criteria, why's he going to the trouble of looking at code in the first place?

I'd be scared if someone were to look at a codebase of component-type-X codebase with a find-fault-fast attitude, if they didn't have extensive experience in designing and building components-type-X already. It sounds like diving head-first into a Dilbert strip or DailyWTF story.

True enough. Archive formats like zip and tar preserve timestamps, but I wouldn't necessarily even trust your average power user to know how to reliably get at them.

Moreover, you have to be careful when uploading new code, when a new idea strikes into your head and you quickly implement a prototype, probably not in a very clean way and without unittests and stuff. This doesn't go well in conjunction with 'release early, release often' rule.

I think if you open source something it's kind of an obligation to clean up and comment your code at least a bit, job search or not.

It's not. When sharing code, there is no obligation to do anything. More people will contribute and share if you have well-documented clean code, but if you just want to throw something up there, that's good too.

Too many people don't contribute at all because the Internet is full of people looking gift horses in the mouth and they figure it's safer to not share at all. And that's not good for anyone.

So sharing a crappy piece of code with poor documentation is better than holding out until you can release a tested product? I don't buy it. Case in point: the many terrible suggestions in the PHP documentation comments.

Yes. It gives the next poor schmuck something to work from.

That's assuming a world, of course, where at least some people actually use free software as something to hack on, rather than as a product to bitch about.

That's so true. Over a year ago, I put a crappy PHP snippet on snipplr and forgot about it. Last week, I came back and found that eight people had saved it and three had left a comment. It's literally just one line of PHP, but it solved a problem for a couple people.

Well, yes, OK, there's no law that says you have to. But it is polite.

IMHO, there is a difference between 'release' something and 'upload on github'. When you releasing stuff, yeah, it should be briefly documented at least, but when you just upload some new thing to hack on it, it's not the same at all.

If that is how many OS wannabes think, no wonder that I have heard that most new projects just sit there taking up server space. "Release early, release often" is for after the initial release; as ESR has noted several places, if you actually want other people to contribute to your project, you have to get it into reasonable shape first, then release it.

For me, new code never goes into a public repository.

I use a private repository in addition to a public one. All partially finished ideas, quick prototypes, etc, go into the private one. If a project ever gets into decent shape, I move it over to a public one.

All code kind of sucks anyway...

Reply on news.ycombinator.com