Hacker News new | comments | ask | show | jobs | submit login
"We've read your code" (jgc.org)
153 points by jgrahamc on Sept 20, 2010 | hide | past | web | favorite | 82 comments

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

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.

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.

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.

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.

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.

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.

All code kind of sucks anyway...

This works both ways.

I have looked at other people's code and screamed, "Who wrote this &%*$^#?!?!?"

Unfortunately, half the time it's my own.

What is your github address?

I think that means that all code you expose to the public should have the date it was created and last modified preferably in the files themselves. If your later code is better than the earlier code, it shows you're learning to program better.

The flip side of this is a job I interviewed for (and actually did take) several years ago. I brought printed copies of some code I'd recently worked on (not sure why I didn't just bring a laptop!).

Towards the end of the interview I brought it out and asked if the interviewer would like to review some of it with me. I was told "No". "Why not?" I asked. "Not everyone has the ability to bring code, and it would be unfair to look at yours if we can't look at everyone's."

I was slightly flabbergasted, thought the logic was 100% wrong, but was offered the job and took it despite that. I was there about 2 years, and the first 18 months or so were generally enjoyable, but nothing lasts forever. :/

Shortly after I started working my first real job, my manager had to attend training regarding how to hire and interview. One of the things they drilled into her was to make all the interviews as alike as possible. You MUST ask each candidate identical questions. Her impression was that this was to protect the company in the event an un-chosen candidate found about the differences and could find some grounds to sue. It's possible your experience sprung from the same lawsuit-averse well.

That's a pathological hiring mentality, it's not a contest, it's an attempt to make your company better by adding new talent. Good interviewers / recruiters use every trick possible to make sure they hire the best candidate.

Some blindness can help you find better candidates - not telling the recruiter whether the candidate is a member of <minority> may actually help quality (while decreasing information), for instance.

Of course, in many/most cases, more information does help. But it's not automatic.

That's what I thought. But when you have an odd view of 'best', then you take odd steps.

That episode sticks with me years later because it was the only time it's ever turned out that way.

We don't all get the time to setup beautiful open-source projects with beautiful tests and code.

I have a number of projects I've started or contributed significantly to that anyone can peruse if they want, but I'm definitely not proud of the code in all of them.

If you use this type of post ( http://blog.jgc.org/2010/09/weve-read-your-code.html ) as a wakeup call to make your code better, that's fine. But, would it make sense to remove open-source projects that aren't your best work, with the rationalization that few if any are using them and they are a bad reflection on your coding skills? If your code is bad and is misleading/doesn't work and provides no benefit to others, take it down or fix it. Otherwise, I say leave it alone, and feel free to leave it attached to your name.

I've met more developers who were afraid (imo) to start or share anything open-source even though they certainly could have (because I was working with them, and I did, without any harm coming to me yet). As Frank Herbert once wrote, "Fear is the mind-killer." Don't let the fear of sharing overtake you.

Why not put up a message on the project's site saying that the code is old, unsupported and not really up to your standard anymore. Maybe list your current projects.

I've been lucky because "John Graham-Cumming" is close to a unique ID.

When my wife and I got married, a couple of years ago, we decided to invent a new name for ourselves. I googled each alternative we came up with, and made sure the name we chose wasn't already taken. Sometimes you get to make your own luck!

Personally, I'd be inclined to go the other way and change my name to John Smith. I'd rather not be easily Googleable by my real name. That's what handles and business names are for.

My name is unique to begin with; I've taken further steps to own it on the internet. I made the mistake of tying it to this username, once, which has led (for better or worse) to a greater discretion under this username.

Yes, once you start to "promote" yourself your personality becomes "public" and different privacy conditions start to apply to you. Don't be surprised of the effects.

Just for my own curiousity: was that your idea or hers?

A bit of both. I wanted us to have the same name, but she is very proud of her French family name and disliked mine a lot (can't blame her - I had always felt the same). We looked through extended family names and couldn't find anything we liked, and then I think it hit us both at about the same time - we could just invent one ;)

Ours was "Sitaker". What was yours?

Moorier. My mother's maiden name is Moore, so we tweaked that a bit to make it sound French (my wife being half French).

Just today I interviewed someone for a programming position. I asked him if any of his code is publicly available (a open source project, a small library, anything) and unfortunately he said no. So now I have to bring him in for a coding interview.

It really saves a lot of time if you have something out there. Just make sure that the first thing one finds is something you want them to see (not some crappy code you wrote two years ago).

A friend was recently asked the same, also said no, and was declined the interview. He is a very capable software developer.

It seems like being active on GitHub is slowly becoming almost a requirement in order to land a good job. I wonder if that is a good thing.

I like your last sentence. I am also sceptical if this is a good thing. And with reason: If you are working as a skilled software architect - and you work on projects under NDA or other laws/contracts for a long time, it could definitely come to the result that you do not have "current code" somewhere out there on github and such sites. And not everybody has the time or the reason to contribute or start an open source project. That even becomes more critical if you want to do other things in your non-working time than coding. If you have the chance to work for a company where you are allowed and instructed to work on open source projects and technology, then you are lucky. But I doubt that the major of software designers does so.

What does he do with the other 16 hours of his day? If I can hire someone who spends 41 hours a week programming, with 1 hour of work that I can actually see, that is going to be a big advantage over someone who claims they are a super-genius architect. Because the first person has documented proof of ability, but the second person just says he's really good.

Don't worry, though. I work with "C++ experts" who don't realize you have to allocate memory before writing to it. Knowing how to program is not a prerequisite to all programming jobs.

I suppose you also need to sleep, so that's 8 hours left of which you spend some preparing/eating food, maybe some sports every once in a while, shopping, socializing etc. Anyway, I'm pretty sure there are people who, while having a passion for software development, feel like doing something else for a change after 8 hours in front of a computer.

If you sleep 8 hours/day, that leaves you with 112 waking hours/week. After work, 1-2 hours of sports a day, you've still got about 50 hours/week.

You can't devote even 2% of that time to building a portfolio and helping possible future employers to evaluate your skills?

"Because the first person has documented proof of ability"

I think this really depends on the position you are trying to fill. A track record of shipping code to customers counts for a lot more in my eyes than open source code (unless we're talking about something really high profile like Firefox or llvm). A lot of really talented and passionate developers are plenty challenged and stimulated at work that they don't feel the need to work on hobby projects in their spare time. What could these people write in one hour that would be of significance?

Only 41 hours a week? Where do they work and are they hiring?

Anywhere? I've never had a job that required more than 40 hours a week.

Some jobs don't "require" more than 40, but when your fellow developers are always there earlier and later than you are, and when your performance reviews go from bad to good after you ratchet up your number of working hours, and when your assignment list keeps growing longer and more urgent, you get the message.

This is probably a sign to change your situation. Start working 40 hours a week, expect bad reviews short term, build a huge open source portfolio using the extra 10-20 hours/wk you've created for yourself by opting out of the sick system.

Next year, you have a better job elsewhere.

This means it's time to change employers and get your 30% raise.

Ya but I think you're missing an important point. Having an active Github can demonstrate a developer with passion instead of one who just sees it as a job.

I know way to many passionate, articulate, and terrible programmers to think passion a good thing. I also know plenty of really great programmers who don't find coding a challenge after all these years. On average I think passion speaks more to youth than the ability to get things done.

>>work on projects under NDA or other laws/contracts for a long time

There are firms that actively ask people NOT to post code outside (citing IPR); and at times, even go ahead and mention that anything a person on it's payroll writes (even if written in leisure time or at home off work), belongs to the firm. The 'extended workplace' clause in terms of contract could be suitably flexed.

It seems like being active on GitHub is slowly becoming almost a requirement in order to land a good job.

You know, there is open source software which isn't on GitHub.

Personally I'm far more impressed with someone who has a commit bit on a project like FreeBSD, because it shows an ability to work together with other people. Having code on GitHub just shows that you're able to fork someone else's work.

There are of course large projects on GitHub, but your point still stands.

Being active with open source communities is definitely a huge advantage, but I wouldn't go as far as to say that you need to be active on GitHub. There are other ways to contribute open code :)

The ideal candidate will do both. It's fine if you just hack other code, and it's fine if everything you make is 100% your own. But the best programmers do both.

"A friend was recently asked the same, also said no, and was declined the interview."

I think that's retarded. There are more effective ways to filter out bad apples. Candidates could be asked to solve a puzzle and attach their solution to their application, for example. Most of the really good developers I know stopped coding in their free time after accumulating about 5-8 years of experience. They have other commitments (wife, kids...) and their day job is challenging enough as it is.

It happened to me but I was given a chance to prove my worth to them. It was a small company (basically a start up) , To cut the whole thing short I ended up with a job and worked with them for 2 years.

I'd never reject someone on that point alone. I'm guilty of not having anything (at least not something I'd like to show) out there too (thou I am working on it).

> And while places like Github and LinkedIn are important parts of your identity, there's nothing more important than a web site that you control. If you haven't registered your domain today, do it.

There's a huge difference between Github and LinkedIn. You can put up content in any format at <username>.github.com. You get a local backup copy of what you put on their as a side effect of using git to push it. The contents of the repo doesn't belong to Github, so you can post it up anywhere. If GitHub disappeared (they won't) or took down your account for some ridiculous reason (they won't), it wouldn't take that long for search engines to be able to find the new location.

If you can't think of an especially good domain name, I don't think picking one up today is a great idea. That said, I have firstlast.com and I recommend getting it to anyone who commonly goes by that combination and has the firstlast.com for their name unregistered.

Finally, I'm surprised how many hackers are using HN or twitter but aren't active on GitHub. GitHub is at least 10x more valuable IMO. (You have to actively use it, of course, to get the value out of it.)

Much love for Github, but if I put my OSS projects there, I do not feel that I get value from them comparable to what I give up by not hosting it on my site. I also think hackers overestimate how many people will read your code (and if it were on your site, you could measure this).

Your A/Bingo site just isn't as useful to me as a GitHub repo would be. I had to clone your repo to see how active your project is. And what if you should lose interest? No link to the "Network" to see where the patches are going. What about bugs? I don't see a bug tracker. And for measuring how many people read my code, well, I think forks and watches on GitHub are a better gauge of the level of interest than that.

We're all businessmen here, and can have a frank discussion about financial reality without anyone getting offended, right?

My ability to eat is, at present, totally dependent on two things: my site continuing to rank highly for bingo-related queries, and (secondarily) my ability to sell fairly expensive consulting services.

A/Bingo exists to make profitable software businesses more money with little marginal cost. It is OSS because it being OSS costs me fairly little and achieves business objectives to me. It is not an act of charity in the slightest: when I donate to charity, the beneficiaries sound more like "my church" or "poor immigrants in desperate circumstances" than "profitable software companies." You gaining from A/Bingo being OSS is a positive externality that I do not optimize for.

Let's talk about the actuarial composite of an active OSS programmer who has two blogs and a Twitter account, shall we? Actuarially speaking, he doesn't link to the libraries he uses: he uses too many, and he very rarely links to any OSS projects these days. When he does link to them, they are typically higher profile projects. On a good day, he tweet about individual libraries he uses. Tweets have an economic value which is epsilon from zero to me.

(If OSS programmers don't typically link to me, who does? Answer: consultants who have implemented A/Bingo and write up about their experience with the intention of drumming up more business, and sites which follow OSS/Rails/etc such as the official Rails blog... whose links, by the way, are worth rather more than links from the actuarial composite programmer's latest blog.)

Let's talk about our actuarial composite programmer, who is a) apparently interested in diving into Rails code and b) insufficiently interested to copy/paste a line into his terminal to do so. Will he make a good consulting lead for me? Well, I do consulting for profitable software firms and can virtually guarantee them "hire me and your bottom line will increase by a measurable percentage." Without going into my exact rates, let's just say they probably would shock the conscience of the actuarial composite programmer, who thinks a) code wants to be freeeeeeee b) he could implement this anyhow and c) "I do not have nearly that amount in my checking account -- what do you offer for the price of a cup of ramen noodles?" (Answer: code available for free, and minimal individualized attention to your concerns.)

Do you see where I'm coming from?

It's not very deep data, but you can get traffic numbers per project by going to Graphs -> Traffic from the project page.

(As an example, here are the numbers for Cyclone: http://github.com/fiorix/cyclone/graphs/traffic )

What do you give up by not hosting your projects on your own site?

Link Juice to your own site. I think Patrick's bingocardcreator.com domain did get good link love because he hosts his A/Bingo project (http://www.bingocardcreator.com/abingo) on his own.

There is also some value to being The Obvious Best Choice on the Internet for A/B testing in Rails as opposed to some smuck who wrote that code that one time. (I get mostly clients who want the expert, and charge accordingly.)

Why would I want to be a talented coder on Github? The place is lousy with them.

I am surprised! I understand what you are saying with respect to keeping the web pages describing your software on your own site, but did not realize that keeping the source code itself on your own site made a significant difference.

Basically how I got my current gig, I knew my (now) boss from some open source work, they were looking for a contractor, and I had a job. No interview, no nothing, just a discussion of the terms and then down to business. Economists like to say complete information generates efficiency (or something to that effect), case in point.

You're quite lucky then. I don't think I've been in an interview where the interviewer had bothered to read any of my code despite it being offered and out in the open. They don't even skim a few headlines from my blog first. I'm lucky if they know my name without reading my resume in front of me.

Do people here think there's any importance to how professional/personal the domain name of your site is? For example, I registered inconsistent.nl (currently sadly empty because I nuked my web server in an experiment and still haven't gotten around to fixing it properly) because it fits my outlook on a lot of parts of the world. And as a bonus it works equally well as a Dutch or English domain. But other people keep telling me it is to unprofessional...

I've been doing freelance work for enterprisey companies from the domain name scattered-thoughts and noone has batted an eyelid. I think for a personal website you're fine as long as its a name you would be comfortable explaining to a client. Obviously if the website is dedicated solely to your business its a different matter.

It's probably better to blast something out there so everyone can see it and possibly offer some advice. I've had plenty of things that were in the experimental phase and left at that. If someone really wants to see what I'm up to or what I'm interested in than it's far better to have said something than to remain quiet and invisible.

I've met far too many programmers who are reluctant to share because they are ashamed of their code but quick to point out someone else's public flaws. It's just easier to criticize than be constructive. If someone isn't releasing memory properly ,in a public repo, then a 2-minute email will straighten that out.

In my last job search I put my resume on my blog (thereby refusing to send out Word files) and pointed potential employers to that, my OSS projects and my HN identity. Seemed to have worked :).

I agree with the author that you will have more opportunities if your code is online.

After graduating, I spent some time putting my personal and class projects on my website. Later in the summer I got a call from a dev manager who found my website accidentally when searching for programming info. He flew me out for an interview and offered me a job.

The job offer gave me the courage to apply where I really wanted to work: Amazon Web Services. It also sped up the Amazon hiring process.

Yeah, so... if you put your code out there as open source, under your own name, a prospective employer might read it. Quite an insight.

"We've read your code."

"I'm so sorry."

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact