7

Possible Duplicates:
How do managers know if a person is a good or a bad programmer?
How to recognize a good programmer?

For your record, I am a programmer myself, and I still do coding. We are not doing your-just-another-CRUD-app, instead we are working on CAD apps.

The nature of software development makes it really hard to gauge a programmer's worth. How can you tell whether a programmer is good or not-so-good?

All programmers who are working with me work on different parts of the applications, and how difficult it is to get those parts working is only known to the person who spend most time in it, in this case it's the programmers themselves; me as an outsider would not be able to fully appreciate the amount of sweat, ingenuity, effort they put in into solving those problems precisely because I don't have a chance to do the same job. This gives me a hard time when I evaluate them. How do I know programmer A is really great at solving the problem at hand and therefore I can throw him a bigger, harder task? And how do I know programmer B is just working hard, but not working smart?

How can I evaluate and compensate programmers fairly?

5
  • They ship on time and budget?
    – user1249
    Commented Aug 24, 2011 at 12:00
  • This isn't a problem unique to programmers. My dad has to keep an electrician for six months to figure out if he knows anything.
    – Steve Jackson
    Commented Aug 24, 2011 at 12:16
  • @Thorbjørn Ravn Andersen > That's only half of the problem. That's obviously a capital point, but if it's done in a way that will incrase maintenance costs or make future evolution harder, this is not the work of a really good programmer. Actually, this is what qualify a good enough programmer, not a godd programmer.
    – deadalnix
    Commented Aug 24, 2011 at 12:24
  • Also a duplicate of What differentiates the exceptional programmers from the really good ones? - we seem to have an almost infinite number of these, and every single time they get mindless upvotes and answers.
    – Aaronaught
    Commented Aug 24, 2011 at 12:44
  • @deadalnix, well, if they keep doing it again and again?
    – user1249
    Commented Aug 24, 2011 at 13:32

3 Answers 3

Reset to default
2

I would like to propose that the term 'good' is conditional. Some programmers are good in one area and not the other. Also, some programmers are good in development of new apps, but can't solve problems in existing apps.

A programmer is good, in my opinion, in a specific project if:

  1. he/she follows standards set

  2. does work on-time

  3. produce good quality work

  4. can understand requirements without too much effort

  5. is a team player to the extent that he/she does not make problems

  6. produces documentation as per project requirements

  7. has good command of his area of expertise without reading books, or expermenting all the time to get the job done

  8. can draw a balance between time/effort/value/complexity

  9. provides more answers than questions

  10. focused on the objectives

  11. willing to accept other opinions and willing to learn new tech.

  12. other personal attitudes (positive attitude, helps other, etc.)

2
  • 1
    You're confusing "good" and "productive". A productive coder will ship a website on time no matter what (or even two!), but he will never design (not use!) something like C++AMP or TPL.
    – Karim Agha
    Commented Feb 23, 2012 at 6:21
  • @kka, you are correct about the fact that I consider good to be productive, I did not think the terms are different before!
    – NoChance
    Commented Feb 23, 2012 at 9:02
1

Regular code reviews. Also measure how long it takes to do projects how many bugs those projects have and how much help they need along the way. That should then give you a rough feel for their worth. Also check job sites for what the market rate for their skill level is.

2
  • 1
    ugh to a place that holds bugs against a programmer.
    – ozz
    Commented Aug 24, 2011 at 12:40
  • Depends on the kind of bugs. If they code in a way that is likely to result in bugs, and the resulting bugs do appear, then yes, I would hold that against them. I once worked with a programmer who not only didn't write {}'s in one-line bodies of if, for, and while statements, and even actively removed them from code he was tweaking. I explained to him that it's easy to create a bug by adding a second line to the body but without adding braces, but he blew me off. Guess what bug I found in his code one day?
    – Kef Schecter
    Commented May 18, 2014 at 12:24
1

There's no simple answer for this one, every programmer has strengths and weaknesses. That really big task they've excelled at might have been perfect for them, but that other one might be totally off-track for what they're good at and they'll seem like a worse developer.

Evaluating how good they are is something that you'd need to do over months rather than tasks, get a feel for how they approach a problem, how they devise their solution and how successful the implementation is. Try them on multiple different tasks, if they're succeeding more than they're sucking then keep trying to see where their limit is. If they just suck then it's pretty easy to tell if they're good or bad.

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