

Ask HN: You watch as someone codes. How long until you know how good they are? - nsheth17

And what gives it away?
======
nostrademons
I think you can tell if they're _bad_ pretty easily, within the first half
hour or so. They won't know where to get started, or they'll start reinventing
common knowledge from first principles.

I think it's very hard to tell if someone is _good_. One of my hobbies when I
was at Google was to occasionally go read through Jeff Dean or Rob Pike's code
reviews, and just look through the code they were writing. On a daily basis,
it really didn't look all that much different from the average Googler's code,
in either output or style. On a monthly basis, they got _a lot_ more done,
through clever re-use of other components, understanding exactly what the
requirements were, and not having to go down blind alleys and re-write stuff.

------
dennybritz
I think that we really need to stop talking about the "quality" of developers
without being able to quantify it. There are lots of different dimensions
among which one can be a good or bad developer, and not all of them are
equally important in all situations.

For example, I know several people who regularly win or get top ranks in
coding competitions. However, they wouldn't be able to produce production-
quality code due to a lack of experience in the industry. Are they "good"
developers or not?

------
greenyoda
Are you talking about a job interview situation, or just watching someone go
about their daily work?

Are you an experienced programmer who can understand what the person you're
watching is doing, or are you non-technical? If you're non-technical, I don't
think you could figure out very much about someone's skills just by watching
them program.

~~~
nsheth17
You're technical. And watching them day to day, like if you were their
(technical) manager

~~~
greenyoda
If I were their manager, I'd be talking to them regularly about their work and
how they intended to approach their assignments. I'd probably be spending time
pair programming with them if they had problems they couldn't solve on their
own. I wouldn't need to try to figure out how good they were just by watching
them. (I was a technical manager in my previous job.)

If I absolutely had to evaluate somebody just by watching them code, I'd use
this heuristic: People who repeatedly try random solutions that don't work are
probably poor programmers - they don't understand their own code, and are not
in control of the process. People who spend a lot of time thinking, reading
the code or tracing execution methodically in their debuggers - and then do
something that quickly works - are probably good programmers. If you want to
have a chance at solving difficult problems, you have to spend more time
thinking and less time typing.

Also, people who spend a lot of time fighting with syntax errors are either
bad programmers or don't know the language they're using very well.

