Hacker News Reader

Comment by untog | Hacker News Reader

One thing something like this misses in comparison to resumes - what was the effect of the code they wrote?

Sure, I can see that you wrote a kick-ass routine to geocode addresses. What problem was it trying to solve? What benefits did it bring to the end user? Did it have an effect on any measured metrics? This is the kind of stuff people usually put in their resumes.

I'm not that interested in the code a developer writes. I want to know what effect they and their code has on the organisation. It's the same reason I dislike recruiters, because they sell candidates to me on "x years in y!"

View on HN

To that end, there is more than just perfection of code. It's great to see a developer write perfect 'debt-free' code, however sometimes it's more valuable to get the code out the door in a simpler easier state.

A lot of developers I've worked with have problems getting to a stopping point. For hiring someone the 'perfect' code usually wins out, yet that person might not be the best fit.

Absolutely agreed. In fact, these kind of hiring services aren't of much interest to me because I think that a lot of developers are "good enough" coders- but that their personality (be it perfectionism, whatever) is more variable.

I'd prioritise finding a developer that is "good enough" and fits well into a team over a razor-sharp developer that can't work to deadlines or participate in meetings.

I often find writing code to be the easiest part of my job. Finding out what the customers are trying to do, what problems they are having doing that and trying to come up with clever ways to solve those with our software is often much harder, and if I was hiring would be a skill I'd care about at least as much as actually being able to write great code. Writing perfect code that doesn't solve a problem people are having isn't that useful from a making money point of view.

> what was the effect of the code they wrote?

More importantly, the context surrounding the code. I could read someone's code, and find it absolutely abhorrent for any number of reasons: aesthetics, functionality, efficiency, and so on. But if what's written is what the customer wanted, needed, or what was appropriate for the problem, the environment, the cost, or any other constraint that fits into "code context", then by all means it's justified, and I'm unfit to judge the person simply by what's on paper.

In fact, I think a lot of insight about the potential new-hire can be gleaned from their answer to: "Can you describe a situation where you decided that the best course of action was to write 'ugly' code? What do you consider 'ugly'? What was more important than having 'clean' code?"

Reply on news.ycombinator.com