
Never judge a programmer by their commit history - MehdiKhalili
http://www.mehdi-khalili.com/never-judge-a-programmer-by-their-commit-history#.UwiURItePPo.hackernews
======
NateDad
If I can't judge you by your code, how should I judge you? Now, that's not to
say that I shouldn't take other things into consideration, like your
experience at the time. Obviously I'd never expect a junior dev's code to look
like someone with 10 years experience. And yes, if you're working at a place
with terrible coding standards, and for some reason I have access to that code
(most of the time those places aren't producing open source code), you can
explain why everything is static public or whatever. That's fine. It's not
like you can't still write good code that is static public... show me how you
write code that is still clear and concise and isolated etc etc even within
the restrictions of the coding standards.

Definitely, you can and should tack on some personal information about the
circumstances around the code you show to people. I have stuff in github that
is half-baked. No big deal. Instead, I say "here, this is an example of my
work that I consider to be high quality, and is an example of the code I would
write for you if given the chance. That other repo is just some stuff I was
messing around with, and I never fully put in the time to make it correct,
because it was just a proof of concept."

And as for personal issues.... sorry, but this is life, and you might have
those when you're working for my company. And I need you to be able to at
least do an acceptable job regardless.

I'm hiring a coder. I'm going to look at your code. Just like if I'm hiring a
cabinet maker, I'm going to look at his cabinets. If he says "sorry I was
tired that week" and shows me crappy cabinets, I'm going to worry that he
might be tired on the week he builds _my_ cabinets.

~~~
MehdiKhalili
I work for ThoughtWorks and here is how they hire: [http://www.mehdi-
khalili.com/joining-thoughtworks](http://www.mehdi-khalili.com/joining-
thoughtworks) It's a pretty involved process but the result is relatively
flawless.

Like you I love to look at code and IMO that's where OSS (Open Source
Software) shines because people contribute to OSS when they feel passionate;
so that should be a good indicator. I also get candidates to submit coding
puzzles and later get them to change it while I am looking over their
shoulders!

RE "I need you to be able to at least do an acceptable job regardless" Until
recently I thought I can always write awesome code; but it's not until we're
brought down to our knees that we appreciate how personal issues could impact
everything in our lives.

~~~
NateDad
Note that I rather specifically said "acceptable" code. That means "not good,
but not terrible". Acceptable can be mediocre. But it shouldn't ever be _bad_.

~~~
chris_wot
Well that's vague. Defined "acceptable"?

~~~
NateDad
I did - mediocre. Neither excellent nor terrible.

~~~
chris_wot
You didn't. I'm looking for specific examples of what you consider "mediocre"
code. I'd love to be able to understand what you this is to you - given it is
so subjective.

~~~
NateDad
Upon thinking about it... I think it's actually what I said to start - neither
good nor terrible. Defining good and terrible code is easier than defining
mediocre code, so we can do it by process of elimination. Mediocre code isn't
terrible, but it's not good code either.

So, what is good code? Testable and well-tested, modular, isolated, easy to
read, robust, performant...

What is terrible code? Well, the opposite of that, but generally there are
some key indicators - code that breaks badly in edge cases, code that is
impossible to read, code that entangles itself in a lot of other code, code
that is hard to test.

So, mediocre code would be something that has some of the properties of good
code, but is missing a few of the more important ones... maybe the tests
aren't fully baked, maybe there are some inefficiencies, maybe it's a little
harder to read than it could be, maybe it's not quite as isolated from the
rest of the code as one might like.

The difference between mediocre and bad is the number of subpar things and
their severity. If there are _no_ tests, that's bad. If the code is horribly
entangled with unrelated code, that's bad. If it's N cubed time in a place
where we expect to handle large amounts of data, that's bad. If it ignores
several common edge cases that will have really bad effects, that's bad.

It is subjective, but it's not entirely opinion, either.

------
rartichoke
It's definitely true. People don't really understand the circumstances the
coder was in when writing the code.

I sometimes come across low paying clients who try to take advantage of you at
every chance. They also come to me with hosting and have even changed hosts
without even asking me while having no tech knowledge (then call me to fix the
million errors they have).

For these clients I usually just throw together some fast low quality hand
rolled PHP sites if they are not very demanding sites. There won't be tests,
I'll haphazardly inline some CSS because when you get paid almost nothing the
last thing you're thinking about is wonderful to work with abstractions that
are maintainable.

You're only thinking about getting the job done as fast as possible and
getting out because you have no interest in doing business with them again and
due to their personality you don't want to be recommended to their friends.

If you compare that code to the code I write for my own side projects or
proper clients it's night and day. You wouldn't even know they are the same
person.

~~~
nailer
I contributed a fix to something on github, making one function signature
which required 'options' have them optional like all the other functions.

Repeated throughout the code base was some copypasta. I dutifully committed
more copypasta.

~~~
rartichoke
Yeah, that reminds me of the broken window tip from the pragmatic programmer
book.

------
whyme
So we've gone from "Don't judge a book by its' cover" to 'Don't judge a book
by its' content'?

How about don't judge anyone until having "walked a mile in their shoes"? Or
even... "Don't judge".

Ideally, "before you judge...", you at least spend some time getting to know
the person to find out a little more about who it is you're judging. And maybe
that's really the issue.

[http://www.goodreads.com/quotes/tag/judge](http://www.goodreads.com/quotes/tag/judge)

~~~
erikb
Guessing applicant quality based on evaluating the information you have about
him is not judging. I can say "this guy is not a good match for our team,
philosophy, and/or strategy" without saying "he is worthless"!

~~~
whyme
Guessing applicant quality is making a judgment of their capability, which is
the core point of the article. I never suggested anyone was judging solely on
a persons worth. I am suggesting that getting to know the person provides
better insight in all regards.

Edit: And quite frankly hiring a programmer solely on programming capability
can often lead to disastrous consequences. So if you can see some higher
quality examples, it's worth investigating - IMHO.

------
tokenrove
The situation is slightly more complex: Programmers write bad code for many
different reasons, but good code only gets written by good programmers. So I
think it's fine to judge someone on their commit history, as long as one is
understanding of the bad code that inevitably happens. The good code doesn't
happen by accident.

~~~
gress
I wish I could upvote this more. I guess a corollary would be that if there is
some good code in a programmer's history, we can ask "what circumstances made
this possible?" and learn how to get the best out of people, rather than
looking to find the worst in them.

------
wreegab
It's nice when acronyms, such as "TDD" and "BDD" here, are expanded at least
once in the text when they first occur -- I don't think it would put a lot of
burden on writers. There is too much of these insider knowledge acronyms all
over the internet nowadays.

Anyways... I gather "TDD" means "Test-Driven Development" and "BDD" means
"Behavior-Driven Development".

~~~
collyw
What the hell is behaviour driven development? Everyone has some sort of
behaviour, so it sounds as if everyone must be practising it.

Recently I spotted a new one, domain driven development. I decided to read up
on it and realised this is how I had been taught to design code, and how I
generally go about doing things. Its got a name now.

~~~
MehdiKhalili
I have explained Behavior Driven Development and its benefits here
[http://www.mehdi-khalili.com/bdd-to-the-rescue](http://www.mehdi-
khalili.com/bdd-to-the-rescue).

Hope it helps.

~~~
collyw
Thanks for that but to be honest it just sound like more of the same, but
viewed from a different angle.

My understanding of your write up is that that tests may be written without
understanding the problem. I mean that is just dumb TDD religious zealots who
would do that sort of thing, assuming that test make up for design (and
thought process). I also think that the verification process is an inherent
part of waterfall model - hence the iterations.

------
fmdud
I think this could be shortened to 'Never judge a programmer'.

Seriously though, outside of an interview environment or training, why are we
trying to assess people's capabilities anyway?

This kind of penis-measuring contest is so prevalent in our industry; it makes
people incredibly afraid of actually putting themselves out there and helping
to create. Judging other people is a bad trait. Simple as that.

~~~
Pacabel
We need to assess people's capabilities so we can try to allocate our
resources as best as we can, especially when facing changing circumstances and
limited budgets.

When assigning work, I need to know if one programmer is likely better than
another at a given task. If Dave tends to work more efficiently with C++ than
Gupta does, I'm going to give the C++ work to Dave. If Gupta tends to work
more efficiently with Visual Basic than Dave does, then I'm going to have
Gupta maintain the old Visual Basic apps.

This is business. We're here to allocate our resources, be they money or
people, as best as we can in order to get the greatest return. Professional
programmers will set aside their emotions in order to achieve this goal, and
will accept being judged as part of the resource allocation process. They
realize that this isn't some fantasy where everybody is happy all of the time,
and nobody's feelings get hurt.

~~~
collyw
I could see a problem with your methodology where someone is "good with
excel", gets to clean up all the shit execl problems, never gets to work on
anything interesting, never gets to improve, or learn the C++, which he may be
better at given 6 months of using it.

~~~
Pacabel
There's nothing stopping such a person from learning additional skills on
their own. There's nothing stopping that person from them asking to prove that
they do have these additional skills. There's nothing stopping that person
from them proving that their new skills provide more value than their old
skills. And if that doesn't work, and their new skills are truly valuable,
then there's a very good chance that somebody else is willing to pay for those
skills.

------
Wheen
As someone who is (Probably a bit more than) a junior dev with no formal
education or experience in a team, do you have any suggestions to write better
code?

I feel like my code would be considered bad, but I have no idea what good or
bad code looks like. Does anyone have some examples and comparisons between
good and bad code?

~~~
sparkie
Really depends on the language and paradigm you're using, but the general aim
for writing good code is to aim for loose coupling, high cohesion, don't
repeat yourself, the single responsibility principle, and the Open/Closed
principle (and several other philosophies) in order to maximize code re-
usability and reduce maintenance effort.

You should aim to use whatever features your language provides to attempt to
enforce the above, by information hiding, encapsulation, avoiding global
mutable state as much as possible, and using design patterns to achieve a good
balance.

You could give two similarly experienced programmers a fairly trivial problem
and they might come up with wildly different solutions, because the _best
solution_ is a myth, but we know the _wrong solution_ if we see it (that comes
from the experience of making the same mistakes.)

If you give details on the language(s) you're using I may be able to point you
to some literature on good design.

~~~
Wheen
Sorry for the late reply.

Recently, mostly Python and Javascript

------
namenotrequired
Good post but why is your name in the title?

~~~
jasonlotito
Most likely it's because the script being used to submit this auto-included
the pages title, which includes his name.

Considering that the official HN submit script† does this, it's an honest
mistake.

†
[http://ycombinator.com/bookmarklet.html](http://ycombinator.com/bookmarklet.html)

~~~
MehdiKhalili
It's AddThis. Fixed. Thanks guys.

~~~
skrebbel
Sorry for being an asshole about it. I deleted my comment.

~~~
MehdiKhalili
Not at all. The post was published by AddThis and I didn't realize the issue.
I am glad it was highlighted so I could fix it sooner than later. Thanks.

------
hanswesterbeek
Agree with the blog. Context is (almost) everything.

------
a3voices
He missed the biggest reason, which is that projects are often coded quickly
to just "get it working" in a fast time frame.

~~~
collyw
yep. I look back at some bits of my own code and realise they are a mess. If
it needs changed anyway, and I have time, I'll use the "fresh look" at my code
to decide what is wrong with it, and what could be better. Refactor from
there.

Another one would be constantly changing requirements. So you start with
something nice. Add a quick hack to do a little more. Rinse, repeat, until it
becomes an unmaintainable mess.

