What makes a "good" programmer? | Hacker News Reader

What makes a "good" programmer?

hasemanonmobile.com

16 pointsedw51914 comments

Most people, when posed with this question, look in a mirror and write 1000 subjective words to describe themselves.

Find me an article that isn't '1000 subjective words' :-)

I actually wrote the linked article in response to all the 'this is what makes a good programmer' articles I've seen going by on Hacker News. It isn't the end-all, it's just more perspective. I'd also add that it doesn't describe me as well as I would like.

Either there's an egoistical interest in articles or this sort or all programmers out there are desperate for self-development direction. If you can answer the question "what should I do next to improve as a programmer?" you're falling into the former category. If you can't, go on a forum/mailing list and ask some programmers better than yourself to ask that question instead of written one-size-fits-all articles on the topic.

There are good articles that fall into the "what is a good programmer" category but generally these have now all already been written. What's left is just opinion and should be taken with a large pinch of salt.

There are good articles that fall into the "what is a good programmer" category but generally these have now all already been written.

"Everything that can be invented has been invented." - US Patent Officer, 1899.

Well, let me put it this way, this article isn't as good as some I've read in the past. I'd love to provide links but I couldn't remember enough about them after 5/10 minutes of searching about and decided it didn't matter that much to me anyway.

I'd be interested to hear your thoughts on what would make it better.

you want me το believe that someone who "blows up" a linked list is a programmer? He may be able το serve other tasks but a programmer he/she is not.

You've never once, under pressure and time constraints, made a stupid, simple, oh-god-i'm-an-idiot mistake? You're a better man/woman than I.

Completely agree. I once had somebody ask me during an interview to write a binary search on the white board. Very tough in that circumstance for me, completely blew it. Interestingly that was 11 years ago, I am now the chief architect and the other fellow has been gone for years. I doubt I could today just stand up and write a binary search from scratch that was worth darn. Even though it is not that tough of a problem.

Programming in my opinion is a reading comprehension skill, solving cute little technical problems won't build large scale maintainable solutions. Even though they are fun to throw around at interviews they don't prove much. :)

"under pressure and time constraints"

Isn't that the situation during a startup and some companies?

If someone is not able to use a linked list, how are you going to trust them think of/implement something new and harder?

And I never said mistakes are unacceptable.

First, I never suggested giving every dummy off the street a pass if they blow the technical portion of the interview. You're right: mistakes are acceptable. Given that, you have to base your decision on whether the person is a match for your needs on more than just a coding exercise during an interview.

Second, and more importantly, a coding exercise during an interview is long, long way from working in a startup, or working of pretty much any kind -- unless you've somehow managed to find a way to get paid for solving toy problems. I've done both, and both are hard, but in different ways. To use running analogies, working in a startup (in my experience) is a relay: you have a team, each of you is carrying your own respective bit of the endeavor, but the success or failure proposition is net across the team. In an interview, you're running a sprint, and all eyes are on you, and you alone. One feels completely different from the other, because it is.

Also, half the times (for a sample size of two) I've been asked to do a code exercise during an interview, the interviewer realized halfway through the exercise that he'd misrepresented the specifications of the widget I was supposed to make. The plural of "anecdote" may not be "data", but I've seen and heard, and can conceive of enough problems with the practice of interview coding exercises that I just can't trust them for anything more than exploring how a candidate approaches programming: the way they think.

Obviously we agree. The "linked list" is the metaphor here. You always should hire the best person that will respond to the needs of his/her role.

The way you write "to" is blowing my mind right now.

I had T9 activated and it automatically choose the Greek word.

Reply on news.ycombinator.com