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.
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.
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.
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.
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.
Applying Pareto's rule to your client list might help improve your life's happiness and hourly rate tremendously. Saying that you need to do bad work because your clients don't pay you well enough is a quite bad excuse.
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.
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"!
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.
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.
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".
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.
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.
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.
So if people are continuously creating unmaintainable messes and technical debt we should just throw up our hands and say "oh well, we shouldn't judge"? Assessing capabilities is required for improvement. If someone is creating poor quality work we can either replace them or train them to do better. But if we can't assess them then we won't know when to do either one.
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.
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?
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.
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.
That was in the MVP (minimum viable product) section. I also referred to an old post of mine, on bad code http://www.mehdi-khalili.com/bad-code, where I explain that in great details. I hope you find that useful.
[+] [-] NateDad|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] Bahamut|12 years ago|reply
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.
[+] [-] GFK_of_xmaspast|12 years ago|reply
[+] [-] tutufan|12 years ago|reply
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.
[+] [-] einhverfr|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] walshemj|12 years ago|reply
I can recall when using mixed case in your FORTRAN IV Hollerith statements was considered a bit flash.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] rartichoke|12 years ago|reply
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|12 years ago|reply
Repeated throughout the code base was some copypasta. I dutifully committed more copypasta.
[+] [-] erikb|12 years ago|reply
[+] [-] whyme|12 years ago|reply
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
[+] [-] MehdiKhalili|12 years ago|reply
[+] [-] erikb|12 years ago|reply
[+] [-] tokenrove|12 years ago|reply
[+] [-] gress|12 years ago|reply
[+] [-] wreegab|12 years ago|reply
Anyways... I gather "TDD" means "Test-Driven Development" and "BDD" means "Behavior-Driven Development".
[+] [-] collyw|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] fmdud|12 years ago|reply
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.
[+] [-] samspot|12 years ago|reply
[+] [-] Pacabel|12 years ago|reply
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.
[+] [-] wreegab|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] acangiano|12 years ago|reply
[+] [-] Wheen|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] namenotrequired|12 years ago|reply
[+] [-] jasonlotito|12 years ago|reply
Considering that the official HN submit script† does this, it's an honest mistake.
† http://ycombinator.com/bookmarklet.html
[+] [-] hanswesterbeek|12 years ago|reply
[+] [-] a3voices|12 years ago|reply
[+] [-] collyw|12 years ago|reply
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.
[+] [-] MehdiKhalili|12 years ago|reply