Slashdot Asks: How Do You Know a Developer is Doing a Good Job?

An anonymous reader writes: One of the easiest ways to evaluate a developer is keeping a tab on the amount of value they provide to a business. But the problem with this approach is that the nature of software development does not make it easy to measure the value a single developer brings. Some managers are aware of this, and they look at the number of lines of code a developer has written. The fewer, the better, many believe. I recently came across this in a blog post, "If you paid your developers per line of code, you would reward the inefficient developers. An analogy to this is writing essays, novels, blog posts, etc. Would you judge a writer solely on the number of words written? Probably not. There are a minimum number of words needed to get a complex point across, but those points get lost when a writer clutters their work with useless sentences. So the lines of code metric doesn't work. The notion of a quantifiable metric for evaluating developers is still attractive though. Some may argue that creating many code branches is the mark of a great developer. Yet I once worked with a developer who would create code branches to hide the fact that he wasn't very productive." Good point. But then, what other options do we have?

Comments

In my experience

[the_Bionic_lemming]

Judge them on bugs. If they are constantly trying to fix their code then you have a metric on when to seek a better one.

Re:In my experience

[Opportunist]

Juniors write code, seniors fix bugs.

That's my approach to that problem at least. And so far I've been doing great with it.

90% of code is trivial bullshit. Anyone can do it, hell, even cargo-cult programming cannot fuck it up. Sitting a senior programmer down to do that is a waste of resources.

10% of code is insanely difficult to figure out, arcane mystical bullshit. Hard to write, hard to maintain, hard to understand and even harder to get right.

You could now either spend time and resources trying to identify those 10%... or you could simply hand the whole jobs of "coloring in your code" to the juniors, watch where they struggle and then set your cracks onto those problems. That serves many purposes.

You eliminate the need to identify those cases.
Your juniors feel valued because they get to work on nontrivial tasks.
It's a very good indicator which of your juniors are really GOOD at their job (hint: The ones that don't ask for help AND still deliver in those 10% cases),
You can keep the amount of high value (and wage) programmers relatively low.
You don't bore your crack programmers with trivial tasks you misidentified as nontrivial.
There is an implicit knowledge transfer from senior to junior

And so on.

That does NOT eliminate the need for good code design, actually, having a good design phase is absolutely crucial to this approach, since else your juniors have to design. That would be ... let's say sub-optimal. You have to give them the outline picture and have them connect the dot and color it in, so to speak.

Re:In my experience

[wisnoskij]

That sort of seems backwards. It is a hell of a lot easier and quicker to not program a bug in the first place, than to find and fix one. Anyone can code, sure, but if you plan on eventfully delivering a bug free program, maybe the poor coders writing poor bug filled code are not really helping with this at all. Perhaps the senior coders, could have written a better functioning, and easier to maintain piece of software alone, way easier than trying to transform a trash-heap of code into something usable.

Management Is Hard

[lazarus]

So this comes down to actually being a good manager. It's hard, and lots of people do it wrong / pretend they are good but aren't / etc. Ask yourself what you really want in a developer and then manage your team to that standard understanding that each member has their own strengths and weaknesses. Something like:

- Elegant and easily understood code
- Good at estimating and meeting deadlines
- Productive and participative in scrums
- Thoughtful and supportive of alternative views
- Etc.

Coders are people. They are a unique breed of people, sure, but if you want to gauge their worth, then you manage and treat them like people. Not monkeys at a typewriter. A small group of talented and creative coders can save a company millions in just a day of work. I've seen it. You need to appreciate their value by paying attention, not coming up with some arbitrary metric that makes your job easier.

Re:Hint: It ain't the guy called in all the time

[Opportunist]

Don't confuse him with the guy that you call at 3am who staggers in drunk and baked, sits down at the terminal and just before passing out and throwing up on the carpet at 3:15am returns your system to a running state despite the problem being in an area he has never worked in nor has any connection to.

That guy you should keep.

Re:Coffee

[gweihir]

From what I have seen in the industry, it is very simple: Either there are no senior developers that deserve the name, or they are not asked on anything that is "management".

I fully agree with you. The job to evaluate technological skills must always be done by a chief engineer (or equivalent). If you do not have a chief engineer, then you cannot evaluate the technological skills of people, and that is it. Other engineering disciplines do understand this. But "coders" are often not even viewed as engineers these days, which is just plain stupid and just another facet of the same problem.

Re:Some methods I use

[lordmage]

Sigh. This is how great developers see bad managers and avoid them.

1. Defect Rate: The more experience, quality developers are given the more complex tasks generally and actually generate a large amount of defects. Defects are also a case of amount of humanity involved in the area developed. More defects in HMI code because of more eyes. Defects are also based on testing, so if a code is rarely used or testing only cursory, defects are not found. This information can be found and highlighted in the FREE Debugging course from Andreas Zeller at udacity.com (Nope not shilling but found this course very informational).

2. Just because someone is an experienced developer does not mean they can estimate a job. One of the hardest things that developers are asked to do is SWAG a job. The numbers are generally way underestimated due to our human overestimation of time in future (look it up, I dont have the time. heh). These times get filtered back through contracts and customers and come back even less time. Exactly how many projects have you been on that actually made time/budget exactly as estimated? There is a reason developers work a lot of unpaid overtime.

3. Testing as you go along. Are you stating all developers should do Test Driven Development? Okay, then provide hard, frozen requirements up front. Oh wait, you are AGILE so that cant happen for larger items. Oh.. there we go.. inch pebbles.. I think the best estimate is down to 3-4 hour chunks of time. Okay, so I established that ETC is hard enough, now do it constantly in a changing requirements weekly. Wait, Im almost done here.. give me some time to finish... I thought I would be done before lunch.. but Im not done yet. Management responsibility is to manage the developer to help them and the management to make realistic time.. so "almost done" is not done.
- Is it Soup? That is what I heard from my bosses when I first started in the game. Is it Soup? 20 minutes from me being first assigned a task. No real concept of the entire task. You learn to answer "Shortly" and they stop asking. 2 weeks if they ask me now.. no matter what it is. They learned to give me real time to get a much better ETC out. One of my early ETC was "3 months" from spending 2 hours on the ETC. When given 3 days, the ETC was a year and it took... a year!

4. Development and constant need to have stuff explained. Verify they understand the first time. Language barriers exist constantly. Yes, this is a decent enough metric but if they can follow computer language logic, they are not dumb. I am at a place where it is expected for new developers to work 18-24 months before becomes productive. Still.. this is one that I can see if you want to cycle engineers to get better ones and do not have a large learning curve for your products.

5. This is general employee issue. Not specific to developers.

KLOC metrics and defect metrics are shown to have real faults when using them to judge a developer.

Things that managers (or leads, including myself) do that slow down/hurt development:
1. Not listen. Most of the time, as a lead, we know it all BUT we are NOT listening and not HEARING why some task will not come close to what we think will happen in the project.
2. Micro Manage. Start the task with a known stopping date and get buy in. Dont go every to them 4 times a day, put them in a fishbowl, look at your watch if they take a longer lunch or go to a doctor, and tell others you dont trust developers as they need to be lorded over (yes, had a manager do this). The developer will come to you when they realize they have issues or need help. You help them by resources, processes, talking, etc but If you then look at them like they are insane.. you will no longer have that trust and you will have way more "Surprises". Here is a metric: If a developer never needs help and has surprises on time and issues... if you are not micro managing them, this issue lies in the developer and they need help on personal time management s