Never judge a programmer by their commit history
mehdi-khalili.com
mehdi-khalili.com
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.
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.
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.
Also, if you don't try to keep your developers happy when something happens, even good developers, they can easily jump ship to another company that does & maybe even get paid better - health issues are nothing to be trifled with, they happen to everyone & good companies will give time off for such for good reason. Even the military with its notorious overworking of people makes sure people have ample time off to recover from illnesses before making an action.
It's by far a pro-developer's job market - I'm looking at about a $70k+ raise in income + stock options over the past 6-7 months with little more than 1 year of experience (from entry level pay & no CS classes in education). If craziness like that can happen, you should beware pushing your developers in the wrong ways since jumping is an attractive option.
This reminds me of the fundamental attribution error[1]. We tend to attribute the motivation behind our own behavior to context we are in, whereas we tend to attribute the behavior of others to internal characteristics.
1. http://en.wikipedia.org/wiki/Fundamental_attribution_error
I judge a programmer by the contributions he or she has made to various open source projects. Now that sounds like judging by code, right? Well only partly. Other things that matter is how many projects someone has committed to, what the people of the project teams say, etc.
The thing is I can't know the context looking at the code. What I can do is look at how successful the open source projects are and what their co-committers have to say. Now, usually the co-committers will say something positive, but what they say is important.
Recently I had to hack the Django test runner, so I could use a copy of my prod database. I hacked it enough to do what I wanted, but I know that releasing that would probably cause people as many problems as it solved, giving them false hope in a solution that worked on my machine with my setup.
I had initially though it would be something the community would want (having googled around to get a solution), but the fact is, to do it an a quality way (one that I would expect to solve more problems than it creates for the average user) would take significantly longer. I don't wnt to pollute good quality projects like Django with crap hacks. I will however be happy to write a blog post or stack overflow answer explaining what I did and how someone else can do the same - with the full understanding it is a bit of a hack, and may or may not affect.
(I have put in the occasional bug report. Am I being too much of a perfectionist for the open source community, assuming that crap code is not better than no code?)
True open source software development is about sharing code because you want to do so. It's not about crafting reams and reams of crappy JavaScript or Ruby code just to be able to claim to be a "prolific contributor", or to brag about having made a large number of GitHub pull requests.
Writing closed-source code that solves real problems is more valuable and important than writing open source software that only serves to stroke one's ego.
(To be honest I've probably lost track of projects that have taken a one-line bugfix/fixup, and if you put me on the spot I'd probably struggle to recall even the biggies.)
Seriously, though, although I think OP overstates it a bit, the point is a good one. When we are paid to code, part of the deal is that we can be required to produce code that is arbitrarily bad, as judged by our own lights. I've certainly been in situations where I was compelled to commit code, in my own name, that I felt was atrocious. You might argue that I should have resigned instead, but when you have a family things are not that simple. (Yes, I did leave with all practical haste, but at my level this can take a while.)
I do judge programmers somewhat by their commits. But I am careful to consider the context, especially parts that might not be immediately obvious. If you see something that looks bad, though, don't just ass. Instead, ask the person about it. What's their opinion of it? What's their opinion of the project as a whole and how it was run? And listen carefully, as standard practice (at least in the US) is to avoid disparaging prior work situations.
Nonono, that's how we judge managers and executives. We judge programmers by their hair.
I can recall when using mixed case in your FORTRAN IV Hollerith statements was considered a bit flash.
"it works" is actually a very small part of good code, since implementation is usually dwarfed by maintenance and extension.
Note, none of what I mentioned is about clever or "purty" 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.
Repeated throughout the code base was some copypasta. I dutifully committed more copypasta.
A lot of them already use shared hosting from previous sites and want to stay with them because it happens to work in their case.
So now you're stuck using some old version of PHP and mysql. What if you haven't bothered spending a ton of time with PHP lately and for the last few years you've been working with node and rails on projects you deem "worthy"?
Should I spend dozens of hours researching best practices for an obsolete version of PHP and make sure I do it right? Or should I lecture someone on reasons why they should allow me to host their site somewhere else and then setup a VPS for them? No frikken way.
Also when you need money, you accept work. That is how the world works. For some people/situations it's not worth throwing away $400 on some job because of annoying clients. You deal with it and put the money in your bank.
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.
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.
Anyways... I gather "TDD" means "Test-Driven Development" and "BDD" means "Behavior-Driven Development".
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.
Hope it helps.
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.
It was quite popular in the ruby community a couple of years ago.
I guess the reason I didn't do it for BDD was that I have written a lot of posts about Behavior/Test Driven Development and incorrectly assumed that my readers know about that. My mistake. It's fixed now. Thanks.
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.
I have had various interviews in the last couple of years. One I got offered the job without so much as any technical test, based on my CV. I almost felt a bit cheated there, as I wanted to prove I was good. I interviewed for a startup with non technical founders. They had pulled a Python test from the internet which seemed 90% about lambdas in Python (I can use them, but in most cases list comprehensions provide a more readable syntax).
I actually like being able to explain my thought process in an interview. Even if I don't get it right, then they may see that I am "almost there". Likewise if I don't know something, I can tell them.
I have a fair idea about my colleges work, not from their code, but by the way they talk about it, and seeing the tools they use. (The "best" in my office of 4 chooses Java for most of his stuff for some reason - not what I would expect from someone good. The worst code was written by someone who ranted about how I should be choosing Python over Perl.)
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.
The phrase "resource allocation" should have tipped us off to how fast and hard this becomes Machiavellian. If one programmer kisses up much better, went to the right school, or is of a preferred race or political party, or successfully claims the work of the other, etc. - the boss will mysteriously find that this one is more competent.
Since the rationale that we decide everything by merit is unassailable and taken for granted, we bias merit judgments to suit our goals. Any objection can be met by accusing the objector of being emotional and wanting to compromise the merit-based system. In reality merit is determined by a political process.
Every single HN poster will, by amazing chance, turn out to be a shining exception to this rule, completely unbiased by personal opinion or politics.
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?
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.
Recently, mostly Python and Javascript
Considering that the official HN submit script† does this, it's an honest mistake.
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.