Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I recently started to learn how to program and am looking to hire a Python developer. How can I separate good code from not so good code?

share|improve this question

closed as too broad by Ixrec, durron597, MichaelT, GlenH7, Snowman Jun 22 at 3:07

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

This question about interviewing a more experienced candidate is probably very relevant, if not an exact duplicate. – Thomas Owens Nov 7 '11 at 19:19
For something like that you need expirience... – Ivan Crojach Karačić Nov 7 '11 at 19:22

3 Answers 3

Read the code. If the code is readable and makes sense to you as a novice, that's a good sign. Good code should be clean and clearly written, with good organization, appropriate use of white space, meaningful names for variables and functions, and comments as necessary.

Run the code. Does it do what it's supposed to do? Another good sign.

Ask the author to explain the code to you. This is perhaps more a test of the author than the code, but it's the author that you're hiring, not the code. If the author can describe the code to a novice like you in a way that makes sense then they surely have a solid understanding of it themselves, and that's yet another good sign. You can also ask the author to critique the code for you -- what if anything would they change, what do they like best, etc.

Finally, ask someone with more experience to review the code. There are a lot of red flags that you can see as a novice, but there are likely to be others that you'll miss completely.

share|improve this answer
+1: "If the code is readable and makes sense to you as a novice, that's a good sign." Like Mozart did with his music, I think a good and experienced programmer should write simple, easy to understand code. Sometimes, unexperienced programmers write cryptic code to prove that they are able to do it, but this does not indicate that they are good programmers. – Giorgio Nov 7 '11 at 21:54

I'm going to assume that you're hiring someone to work on a project for you individually and not as part of a larger company. If you looking to hire someone as part of a larger company on existing projects, try asking for help from within (HR, other developers, etc).

First, if you want to hire someone to help you build/maintain an application, ask about projects they've worked on previously. How did the project end up? Do applications from it still exist? Does the code still work? If someone is actively using a particular language and has worked on successful projects, that's evidence (but not proof) that they are a good coder and produce code of good quality. It's somewhat weak evidence but there it is.

Also, if the applications still exist, try using them. Do they appear to work well? Is there evidence they've been well designed? Tested? Are they awkward or have an awful UI? If an application functions well and "feels" good as an end user, that's more evidence the coder produces good quality code. If the application feels thrown together or very poorly thought out, that's evidence of lower quality code.

Lastly, find (probably Open Source) applications that you think are good applications and read some of the source code. Look for unit tests, coding style and overall structure. The more code you read, the more you'll be able to identify "good" and "bad" code. You can also practice writing code and read up on language features and idioms to get more a feel for particular languages (Python, like many languages, has particular quirks and idioms, broadly captured in the The Zen of Python)

share|improve this answer

Gross generalization alert!

The two main factors you'd want to watch for in pretty much any language are:

  • Portability: Can the code be easily modified for expanding needs, alternatives, etc (versus how are things tight locked, hardcoded, etc)?
  • Testability: Is the code structured so that it can be tested?

There might be more, but this is as general as it gets, IMHO.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.