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.
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.
Besides some publicity, partly due to key person's popular books/blog I believe, why is ThoughtWorks special? I mean, isn't it just yet another enterprise/CRUD app development shop?
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.
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.
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.
Context matters with code was the point, not necessarily the code itself in isolation. We've all written bad code due to time hacks or bad architecture/bad code elsewhere.
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.
Excellent point, it's definitely the context that matters. To me the article is arguing "code is not written in a vacuum" rather than literally "don't judge coders by their code."
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.
I would make it part of the interview. Look at the code, think about it & ask the programmer about it. Reserve judgements until you have made an attempt to learn something about the context.
If the only code somebody shows is code they make excuses for, that's a red flag, but shit does happen in life and if you're not the type of boss who can deal with that, then you're not the type of boss I want to be working for.
I didn't say shit never happens. Of course, take time off, work shifted hours, do what you need to do. But don't check in shit code and then make excuses. Crappy code is worse than no code at all.
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.
> If I can't judge you by your code, how should I judge you?
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.
So how would you judge someone like me who has no open source projects? Work stuff is in house, and I don't have the time outside of work to contribute anything meaningful.
Do you use any open source libraries at work? Are they flawed? Write good bug reports and get involved in the community. It's not building up a patch portfolio (I should trademark that) but it shows that you're paying attention and care about quality.
Python libraries are usually rock solid. Perl modules in CPAN before that. Now I have been playing with Javascript recently, and that is a whole different story. Unfortunately my JS isn't good enough to improve what has been done.
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?)
Don't worry about not having made many or even any open source code contributions. You probably don't want to work for or with any person or any organization that will judge you negatively based on that.
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.
All of the companies I have ever worked for directly or indirectly disallow open-source contributions through employment IP agreements. If you are working for somebody else in technology world, there is a good chance that you also have signed such an agreement already.
Yea. That is not to say we (generally people working for such companies) don't contribute to open source, it's just not gonna look like it's coming from you. We will routinely file internal bug reports on our open source tools, but our stuff is tweaked a bit. Also some of the open source stuff we use is actually developed 90% in house and open sourced by US - you'll definitely never see our contributions or bug reports then, because it's all done on our internal codebase & tools.
I would prefer to hire people I know than those who don't, but if you have worked on successful, related projects then I would ask for references including co-worker/developer references.
Interesting perspective. I both write code, and contribute fixes. I've had my code end up in screen, emacs, and other tools that people use but I've virtually never advertised that.
(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.)
That's the kind of contribution I do (plus some translations). I don't even have it written down because it's so minuscule compared with the work people do on those projects I don't think it merits attention.
Good code is more than how it looks. Is it fault tolerant? Does it handle edge cases? Does it scale? Does it lend itself to being tested? Does it lend itself to being extended? Is it legible by other coders for when they inevitably need to fix bugs and/or refactor / extend it?
"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.
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.