Slashdot Mirror
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?
When the coffee machine runs out :D
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
This occupation is slated for automation.
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.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
Does the software work properly in accomplishing its objective. How many failures are observed in either testing or live work.
Here's a clue:
It's NOT the guy who always gets called in at 3 AM to fix something that HE wrote.
He's NOT your "hero". He'e the moron you need to fire.
I would measure and evaluate the test cases.
They are easier to digest, quick to summarise and the test case can describe the complexity of the function as well as the failure modes it protects against.
If the job is getting done in a timely, not ridiculous timelines put together by clueless pointy-haired-ignoramouses, fashion, even in the face of idiotic interference by said PHI trying to tell a programmer how to program, or how to interpret the design documents even though they have absolutely no clue, then the programmer(s) are damned good.
It the project is still moving forward with only 1 or 2 American programmers having to decode, debug, and in most cases completely rewrite the absolute crap put out by the outsourced programmer wannabes from who knows where, then the programmer(s) are damned good.
I think the more important questions are:
How do you know if your manager is an imbecile that should be fired?
How do you know if the company you've outsourced your work to is bad enough that you should fire your manager?
When he can keep deadlines within reason and deliver something that runs pretty well based on the specifications. Anything else is fluff.
We have this on guy who we wanted to dump as he just did not file them the right way But he just got pushed up to management. And they one of older guys who got layed off burned the office down.
When he hasn't murdered the management asking if he is doing a good job....
Do not look at laser with remaining good eye.
There are a few ways. SCRUM/Kanban is an effective way to inundate your programmers with meetings and conference calls asking and tracking minute status updates for every commit or stash you can find. its perfect to ensure that changes to the codebase are governed by your personal fears and demons, not the best interests of users, because you too have to be fully invested in standing up in a conference room every morning and listening to a dozen or more different and often pedantic events transpiring in the cubes of people that know far more about them than you. Agile can be used to boost your title and sometimes salary while at the same time demeaning a team of programmers into thinking theyve signed on to some late chapter of Orwells 1984.
Or you can set goals, track them in a ticket system, and evaluate results based on what your users and teesters see and want. Call people in for meetings when there are big events, but otherwise keep your hand off the phone and use something called trust to ensure your programmers are "doing a good job" once the code is ready.
Good people go to bed earlier.
Look at what the developers write, evaluate their work. An experienced developer is capable of evaluating other developers. A manager without programming experience may have a hard time though.
There is the quality of the code written. Beginner code or better stuff? Clever stuff? Handles corner cases well or not? Passes reviews/testing better than others? Good documentation or just some mandatory template documentation?
How did they handle the unexpected, such as a key library not working as advertised? Fixed it? Made his own implementation? Complained to the vendor and just waited forever? Capable of fixing things when some other developer has made a mess?
For an individual, I don't know if there is a way. But there's some guides. I go off of how frequently do the projects developers work on succeed or fail and how many problems do they tend to have in those projects as well as how far behind schedule do they tend to be. You can't use a single project as a metric, but have to look for trends. For example, you notice that projects tend to do better with certain developers and some do more poorly with others. But again, this isn't fool proof because it's all a team effort and the best and brightest can't pull up a crap team, and a really good team will still succeed even if one member is garbage.
Really, I guess it's that you really can't judge developers as individuals and instead must judge them as groups.
The ones doing a good job are NOT wasting their time on slashdot.
And now back to work!
P.S. I'm probably closer to the weekend than most of you :-)
bickerdyke
That's easy? OK, problem solved.
Wait, it's not easy?
-Dave
Doesn't indicate much of anything. Merging them into your release branch does. Branches can be features of bug fixes of course.
A developer is doing a good job when you can observe improvement in their skill level every quarter or year. If their skills have stopped growing then they are at best doing an adequate job.
Manager bros/bras hate the idea that people aren't machines with objective measurements open to checking by someone with zero domain knowledge.
I don't think it is possible to grade on any metric.
Project I am managing now there was a "superstar" programmer - or so it was thought. The project would not have been successful without his work for sure but ... Every line of code he wrote is terrible. It serves the purpose intended but its unreadable and cannot be extended at all. I have yet to find anything he wrote that could be extended to a useful degree and I am not alone. If he had not been a programmer at the time the project would have failed completely yet his work has a super high ongoing cost. Should he be rewarded for pulling a miracle at the time or castigated as a failure now?
Another developer just starting out. Regular coaching etc. and seemed to be getting the hang of things but ... could or would not take the smallest initiative. Caution is a good trait when starting out but at a certain point the expectation becomes different. You have someone capable of the job but they need continuous hand holding. OTOH Code hygeine was good. I haven't had any problems reading their code or extending it.
Who gets the glory, who gets the boot?
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.
I am not interested in articles about life extension advancements.
Good is relative to the other developers on the team and the standards for the company.The Team Lead, PM or in some cases Architect should be competent with the design patterns being used on the project and the performance of the other developers on the team. A developer is doing a bad job when their output isn't matching the output of the other team members in terms of performance or when they are refusing to follow design patterns and other standards set forth by the supervisors... It gets more complicated though, Poor performance and non compliant code could be tied to a need for training the employee didn't receive. It could also be tied to specific time delays/blockers they had to overcome. So all this has to be considered. Once everything that can be done for developer has been and the pattern continues to repeat, you know there is an issue.
If he's rockin Ivanka's clothing line and buying her stuff like a good citizen, he's clearly a good developer.
- Bill Gates
-Dave
In other words: You have to be one to know one. A developer knows who is a good, productive developer and who isn't. Be a developer, at least in part.
Here are some methods I use to determine if they are doing a good job.
1. Defect rate - If they are constantly fixing bugs or you are required to have other developers go over their code and are constant finding basic problems, the developer isn't doing a good job.
2. Taking more time than expected/estimated to do a job. Obviously there's cases where requirements change or unknown issues pop up in the project. But if it's a constant issue, then there is either a problem with management/planning, or the developer isn't making good use of their time.
3. They constantly say "I'm (almost) done, just need to test". A good developer will test as they go along. Once the coding is done there should be very little additional testing that needs to be done. You reasonably certain that everything will work by the time coding is completed.
4. Constant needing to have stuff explained to them. If you constantly need to explain how something is supposed to be done, or have to explain the project 3 or 4 times, then the developer may have a problem. It may also be the case that you aren't explaining the project properly, however, a good developer will ask for clarification up-front instead of nodding yes, and coming back 3 days later with a bunch of questions, no code to show for the passage of time, or maybe even worse, a bunch of code that doesn't do what it's supposed to.
5. Finally, sleeping on the job, constantly late, or going home early or a combination of the above. You wouldn't think that sleeping on the job would be a big thing, but I've seen it happen more often than not. The causes of this could be anything from just bad time management to other things that are more understandable like a personal illness or a sick child/spouse or other personal problem. But the reason doesn't change the fact that the person is going to have performance problems. The employer should identify the problem and work with the employee to resolve the issue.
Finally. It's all about taking metrics in terms of defect rates and whether or not projects are completed on schedule. If they are doing well in these areas, they are probably doing a good job. The other stuff like showing up late or sleeping on the job really shouldn't matter that much as long as the person is getting their work done. But I haven't met a whole lot of people who can sleep/slack off at work while still getting the job done.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
It's called social interaction.
A good programmer will be able to explain what he's doing. A good programmer will also be able to tell you that sending out that offer and requirements analysis before showing it to him or somebody else who will do the programming is a very very bad idea. And that you really should have him on board when planning the project. But you do have to listen.
If there is no social interaction (which may be formalised with Scrum or something), then you will never know what he is doing. And he won't care to do a good job because you don't care about what is required to do a good job.
Talk to each other. Every day. You learn very quickly how much worth a person is that way, no matter how far away you are from being an expert in the other persons field.
It's that simple.
We suffer more in our imagination than in reality. - Seneca
Terrific, I had top score on the bugs chart in my office. It got so bad, people would list bugs to be off JIRA so management wouldn't notice and wouldn't sack me.
Why did they do that? Simple, I was writing 80% of a new product. So a) OF COURSE I WOULD PRODUCE THE MOST BUGS from the volume of work and b) OF COURSE I WOULD PRODUCT THE MOST BUGS from the newness of the work.
IMHO it's not hard to tell whose delivering, because you have requirements and those requirements are met or not and this is obvious to the people who raised the requirements. And seriously, if you have a business and it has a product and your profits depend on that product, and you're so incompetent you don't know whose delivering your product, the person to sack is yourself. You're out of touch and serve no purpose.
You have to a) know how to program yourself and b) be a good manager before you can judge whether a particular person is "good". All other 'metrics' whether it's number of bugs created/resolved, time taken, lines of code written, mean time between failures, are useless if you don't know how they relate to your existing code base and impacted the actual work being done. If your software is written in brainfuck (or one of the P's - PHP, Perl and Python) you can't blame the developer for time taken to resolve past mistakes, on the other hand if it's written in one of the C flavors, you can't blame them for writing a bunch of memory management code or having various memory leak bugs, and if any of your tools includes the words Visual, then you got shitty developers to begin with and you can't hire anything better.
Custom electronics and digital signage for your business: www.evcircuits.com
I don't know about where other people work. But for me the process is, customer requests something, I build the request, customer is satisfied with the result, boss is happy with me. Wash, rinse, repeat.
Does it really need to be more complicated than that?
This fact has been known for a long, long time:
A good decision is based on knowledge and not on numbers. -- Plato
Yet these morons are _still_ looking for the "magic" numbers that can replace understanding, millennia later. The only thing that works is a "Chief Coder" or "Chief Engineer", who must be very competent, both technologically and with regards to social skills. That person will know. Of course, such people are rare, but nothing else works.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
"I am a pointy haired boss who wants to treat my employees like I treat my fantasy baseball team. Please give me a stat system so that I can rank them and start abusing/eliminating the ones who end up ranked lowest."
Good code and good coders are not simple things to evaluate one a one or two dimensional graph, yet the whole idea of metrics is to simplify the evaluation to one or two objective numbers.
As already pointed out in this discussion, selection or emphasis of a metric will always change developer behavior. If the emphasis is on the number of tickets I resolve, I'll make sure I write a ticket for every change I submit because I want to get credit.
So why don't senior/lead developers who are familiar with developers work on a meaningful level weed these people out? I think the choice of metrics is made by managers who aren't hands on, looking for a way evaluate the stuff that they don't interact with regularly. Those senior/leads that are familiar aren't empowered. This also quickly becomes a politics thing. Everyone has worked with 'that guy', who everyone but senior management knows can't do their job.
...One of the easiest ways to evaluate a developer is keeping a tab on the amount of value they provide to a business. ...
... you need to look at things that are under her/his control. If the developer is placed on low-value projects, then the value of that developer is low. Does that mean the developer is no good? Evaluating the value of a developer to the company may be more of an evaluation of management than the developer.
Were inspired, in part, by this very question.
I think it's a really hard thing to quantify a 'good job' for a developer? The amount of context and work scenarios would make your head explode, honestly.
What if we were talking a one to two developer shop where hackish amateurism and 5-minute produced Wordpress sites seems like 'magic' and just 'works'? On the complete other side of the spectrum with your Google, Facebook, Amazon, Snapchat, Instagram, and Microsoft's of the world in terms of fixing an ultra complex situation in 5 minutes that's nearly bulletproof in terms of 'all the bases covered' with minimal room for turnover on not getting it right the first time?
I'd agree with most on here that, to me, at the end of the day, it takes one to know one --- ESPECIALLY when you've had to do any software development in any context in the real-world, support it and have a business function rely on it. I've had SO many developers try to tell me how 'awesome' they are and say "I have two bazillion lines tied into" and I think with enough experience to sniff that out, it's either _that_ complex or it's bullshit. And I think the other thing is the functionality piece. It has to work, work well and not just accomplish more than the bare minimum (from the start).
Look what most of us do when we have a car issue and don't know shit about being a auto/engine mechanic? We take their word with whatever shit they tell you is wrong as long as we get a working-like-we-had car back in return? That 'progress' could be that it took 5 minutes to get your car fixed and ran with your 10 hours of labor straight out of your checkbook. But if I was any sort of mechanic, I could rightfully call them out, right?
On team development, it's pretty straight forward, although requires 2 agile tools: daily meetings && code reviews. Even if not using full-fledged Scrum, daily meetings (or at the very least, every other day; weekly defeats the purpose) are essential both to enforcing lazy/demotivated coders to code, and to keep everyone "up to speed" on each devs, well, speed (velocity). Some will argue there are devs that can mask it out pretty well on dailies, but in the long run, it's impossible not to notice when a dev is boasting of things he didn't/won't do, and in that moment, he either self-corrects (he also notices when he gets caught), or he needs punitive action (harsh, but true). Code-review is just a natural iteration to what dailies provide - you complement the generalized opinion with his code - if it was made for general scenarios and considers plausible edge cases (as opposed to solving it for a specific edge-case, which is usually the highest indicator of a bad dev) and the quality of the code overall, although this last part is highly subjective and that's why code review needs to rotate around so a collective opinion around each dev is maintained.
Now, checking stuff like one-man army freelancers, that's a lot harder. There's no other dev to compare, no other dev to supervise. It's like going out for a meal: you can't really look in the kitchen, you get the dish and that's what you can evaluate. Arguably some might have found better tools for assessing small or single-people projects, but it's just hard. The only thing I can say is: as soon as you get 2 devs that don't happen to be biased (e.g. best friends, family), it is much easier to assess each other's value in the project.
On the article itself I have to say: LOCs are plain stupid. Some devs don't even write a LOC all week, yet they are more valuable than others that write LOCs efficiently, but simply work on less important features. A "build master" (or whatever u call the guy handling build automation these days) can be months without writting a LOC, yet he's no sysadmin: he finds bugs, he points other devs to code-parts of bugs. He gets to find failing test problems, regression issues among others before it even gets to QA. But that's just an example. Who has never solved a critical issue 3 other competent people had checked with a one-liner (or even a "one-character"). Sometimes luck is part of the job, other times yu simply are the guy who had the correct line of thought to approach the thing. LOCs are irrelevant in most "valuable" scenarios these days, especially in app maintenance, which is 80% of the industry cost.
The notion of a quantifiable metric for evaluating developers is still attractive though.
A metric is attractive to those who like metrics. Typically such metrics are desired by managers and other non-technical folks who don’t actually fully understand what the engineers are doing and so desire to rely on a number to evaluate productivity, because they can't easily evaluate it via other methods. However, that actually isn’t a great idea.
Holism, combined with developers who can both comprehend and communicate what and how engineers are developing is better than metrics.
Think about this like you were evaluating painters. Will number of brushstrokes work? No. Will number of paintings work? No.
Will relying on holism rather than metrics work? Yes.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
God help you if you try to get rid of someone who is doing negative work...when it'd be cheaper to pay them to sit at their desk and not touch anything...if they happen to be in some protected class. Been there, done that.
Without reading through any of the comments, I predict that 90% of them will be "the only good developer is me, everybody else is an idiot".
Proud neuron in the Slashdot hivemind since 2002.
I once worked for a startup and I was very productive. I build two new products from a remote location for the company that resulted in tens of $Millions in new sales. I would work all day from a quiet place all by myself (no meetings, interruptions, etc.). A few years later, the company changed management and they wanted to 'cut the fat' from development. I happened to be working part-time at the time (recovering from burn-out) but was still very productive. It didn't matter at all to those bean counters that they were getting multiple dollars in value from me for every dollar they paid me, and they let me go. Luckily, I had founders stock and made out pretty well when the company sold. Otherwise, I would have been very ticked. I'm sure they used some meaningless statistic to justify getting rid of some really good programmers.
I suggest having standardized JAVA-Doc-like syntax where users can rate functions and add virtual likes/dislikes to whatever code they want.
Because what is better code then a code that does the job (nobody has to fight with it), is readable, understandable, manage-able... simply code that users (other programmers) like to use?
S why not to have /** ... ...
*
* @rating elixon +1 Some optional comment.
*
*/
That way one can even identify problem parts in a code that are difficult to work - that slow down other programmers so it can be refactored... :-) I would love it. I would give my @rating thumbs up and down like crazy...
Well, I've got to get back to work. When I stop rowing, the slave ship just goes in circles.
It's a multi-state, multi-variable issue and depends what kind of development the developer is doing.
As an example, when I'm doing low ever firmware development, things I would measure as success:
1. Robustness of solution.
2. Efficiency of Code.
3. Preform a LINT / leak scanner and look at that output.
4. Speed of module / driver / support coding.
5. How they handle library and portability in their development.
6. Security and complexity in terms of O and o.
Web Frontend Development:
1. How their work scales across different browsers and resolutions.
2. Engagment, look and feel.
3. Lines of code to implement certain aspects, less (usually) better.
4. Framework engagement, for instance using Angular.JS instead of rolling their own.
5. Knowing / applying stuff like jQuery or knowing not to.
6. How they implement REST services.
If I'm doing Server End work, I'll have a completely different set of requirements, same with desktop frontend, backend and etc....
I have never understood the point of SCRUM/Kanban, and the 3-4 hour physical "stand up" meetings daily that go as the following:
Person 1: "I can't do any work, I'm blocked by so-and-so."
So-and-so: "You never asked me to do 'x'."
Person 1: "I am still blocked."
Person 1 then goes to wring his/her hands about stuff, lash out at others how slow things are going.
Then the PM starts grilling people about stuff, a clueless person questioning the coders about virtually every pull request. "Why does a typo have to be corrected?", "Who cares about this security thing, we need this shipped, not secure.", and so on.
Person 2 gets up. Same song and dance, with the PM questioning everything.
Then after the other people have their tales of woe, the PM starts the lecture about something or the other. People come back to defend themselves.
Meeting then breaks up into a quibble session, with people pointing fingers. As an IT guy, the DBAs are requesting their dogshit-slow multi-TB tables be on all SSD, and no, they are not going to ever make index tables even when the performance tools show the bottlenecks, because they feel it won't help things.
I wound up taking lunch at 2:00 to 3:00, come back, maybe get 1-2 hours of actual work in, and that's the end of the day. The next day, I try to slide in an hour or so before the next stand-up meeting.
Thankfully, I quit that place... but can someone explain the business reason for multi-hour daily standup meetings? They do -nothing- for productivity, and every hour I'm in a meeting room is an hour that nothing is getting done.
Yeah, just make sure to shutdown the computer before sleeeeeeeeeeeeeeeeeeee Filter error: Too much repetition.
aaaaaaa
It does if you want to justify your entirely worthless "management" position, yes. Just as HR requires stupid and pointless hoops to have been jumped, just as interviewers insist "coding problems" are meaningful, etc.
IOW, most of the structure of the coding side of operations is redundant, pointless, doesn't do what it's supposed to do and to whatever extent it does anything at all, it's almost universally the wrong thing.
Find a way to be self-employed. Then you have motivation, sane tasking, and a perfectly closed feedback loop on productivity, quality, maintainability, extensibility, modularity, and income.
So sad I already used up my mod points above. Virtual +1, insightful.
Feature importance * lines of code / CPU time required to run code = score
That's a pretty good answer.
I'll add a few thoughts. First, this is a very, very hard thing to do. In all likelihood, there is no truly effective way to "measure" the effectiveness of a programmer, we're looking for hints, traits that good programmers often have.
You may have much less desire to measure anything about the programmer, though, if each person is responsible for a specific area. If one person is responsible for building and the maintaining the UI for product ABC, while another person does the UI for product XYZ, you can answer a simple question. Does the UI for ABC suck? If the UI he built sucks, he might suck at building UIs. Unless of course he told management ahead of time that no, you can't build a good UI under the constraints he was given (time, tooling, etc.) Of course you can do that only if your programmers specialize in particular areas (which also allows them to become more expert in what they are actually doing).
Other than that, there are heuristics, hints about who might be good. Does the person ask questions about the requirements, making sure to build what users actually need? A lot of really good programmers spend a lot of time to fully understand and document exactly what is needed. A lot of bad programmers run off and build something that doesn't fit the need. (Obviously this fails if you TELL the programmer "your next raise will be based on how many questions you ask).
Do other programmers come to this person for advice? If so, not only is that a compliment, but by giving good advice he's probably making other programmers more productive.
Do they enter useful comments in the ticket system, close issues when they complete them, and generally be a responsible adult about following processes? This *can* be misleading, but generally, people who are careful to do a good job are careful to do a good job. Someone who marks issues as "closed" when they are supposed to and completes their annual compliance training in time *might* be someone who validates their inputs when they are supposed to and completes their coding work on time. (Or not, it's just a hint).
Even if you're not a programmer, you can actually get a slight hint by looking at the code. When you see a Slashdot comment that is a wall of text with no line breaks, no punctuation, and no capital letters, you might suspect that the writer is less conscientious than someone who uses paragraphs, punctuation, etc. This is even more true of code. If you squint so the characters are blurry, good code tends to look like a diagram of itself. Bad code tends to look like a blob. This is hard to express, though it's easy to do. The Linux kernel source is good example of good code (in most cases). Indentation sets of clear logical blocks, etc, so the code resembles a diagram.
Heck even without opening any code file, you can look at the names and organization of the files the programmer creates. The newbie/bad programmer may have one giant file, called "myprogram". The expert is more likely to have one small file and two or three subdirectories at the top of the project. He might have directories (folders) called "libs/", "logic/", and "ui/". Under libs/ might be two subdirectories, say network/ and db/. That's a great sign because programming well is largely a process of organizing ideas. If a programmer has organized the task into understandable parts, that is a good indicator.
I could go on, but the point is there are lots of hints you can look at. Like buying a used car, you can't look inside the engine to see what condition it's in, but you can reason that if someone let the tires go completely bald and the interior is covered with coffee stains, it it obviously hasn't been vacummed in the last six years, they may have also skipped an oil change or two.
Not that difficult if your developers work off a bug and feature log. The managers should assign bugs and features to the developers, and over time the daily average of bugs successfully closed, or features accepted for a build per day is a pretty good metric. I don't think it is hard if you have good processes and track everything with a bug and feature log.
Every time a "serious" defect is found, figure out who is to blame. It will usually be the person who wrote the code, but may not always be that person. For instance, if he or she relied on behavior from someone else's code that was falsely advertised. Or if he was given inadequate requirements. If a particular developer is disproportionately frequently to blame for major problems, then that person probably isn't a good developer. Also take into account total output and "sensitivity" of what someone's working on. A developer who does a lot is going to cause more issues, simply because he's doing more. Likewise, a developer working on "tricky stuff" (e.g. refactoring terrible legacy code) is more likely to cause issues simply because of the sensitive nature of the code he's working with.
Seems this question is the one that is rarely asked and even more rarely actually defined. If gathering metrics and making blanket decisions about people from them is the measure of a good manager, I'm positive we can write an application to automate them out of a job.
Honestly I don't think that being a great developer is quantifiable in the sense that you can feed some metrics into an equation and come up with a number. If you do that, even poor developers are smart enough to work the system.
Here are some signs of a good developer, IMO:
* Writes code that can be easily understood, even when the task at hand is relatively complex.
* Removes code on a regular basis. (Net LOC added might even be negative)
* Asks good questions to clarify requirements.
* Produces good tests, uses them to validate the code they've written.
* Makes proper use of libraries instead of "re-inventing the wheel".
* Makes good review comments on other developer's code that make it cleaner, more testable etc.
* Documents complex systems so that the next poor sap who owns it won't be completely lost.
Obviously if you're measuring by LOC added, stop it. That's in direct opposition to most of these principles.
Make sure the measurements accurately reflect what you care about. What is code quality for you? Do you care about customers not encountering bugs? (All bugs? Just critical?) Do you care about development speed not being reduced gradually? Do you care about estimates matching actual time spent, so you can plan ahead? If you don't actually care about how many lines of code are committed to the git repository, then obviously don't measure it!
And if you can't measure something for each team member individually, make the whole team equally accountable for the end result. They will figure it out themselves and tell you who's bringing the team down. Not just that, once they know what you really want, they'll also be able to suggest how to measure it better, or tell you what you can do to let them achieve greater results. (E.g., faster PC, bigger monitor, fewer distractions, no scope changes, better test environment, specific training, etc.)
Define job first, then define the parameters of average, above and below average. Then you may get to a point of defining good.
In the majority of the cases, "good" is a perception by management for management purposes.
If you ask this question, then I would say that you shouldn't have a job where it's necessary to know.
I'm not trying to troll you, but this is important to understand.
I'm a developer as well as a business owner. I understand that it would be fantastic if we could have a meaningful set of KPIs on developers. But they do not exist. Sure, you can create them, but they will be wrong.
For example, bugs. My best developers also create the most amount of bugs. Because I naturally assign them to the hardest part of the application and they usually write the largest number of new lines of code.
I'll also say that any talented software manager I have met, have not needed a set of metrics on the developers in the teams. They know who is good and who is bad.
Certainly one can create a large and unintuitive, meaningless jumble of folders. If just the *names* of the folders aren't meaningful to other programmers, that's a bad sign - even before you know what's in the folders.
That said, smaller projects have an amazing tendency to grow larger. Programming projects very rarely get smaller (unless a genius points out that rather than writing a new system, you can just transform the inputs and feed the data to an existing system*). Because projects tend to get much bigger over time, I much prefer more organization than less. You'll be very glad for the organized structure as your 1,000-line program evolves into a 100,000-line system.
While most projects grow, not shrink, I'm thinking specifically of some projects I worked on which ended up being literally 1000X larger than originally planned.
For the same reason, I prefer a slightly more powerful programming language over a slightly simpler one - a shell script may work for *todays* needs, but next month we'll have to rewrite it in Perl or Python to handle some new requirement cleanly, or else end up with a giant, unmaintainable, fragile shell script. Similarly, a very small shop should start using version control *now*, not *after* they become a big business and much of the history of the code has already been lost.
I said:
Programming projects very rarely get smaller (unless a genius points out that rather than writing a new system, you can just transform the inputs and feed the data to an existing system*).
I forgot to expand that asterisk in a footnote. When you're planning an eight-week project and one developer says "no need for all that, I can do it in two days by just running Foo on it, then sending it to the existing Bar tool", that person is either a genius who will save you lots of time and money, or a complete hack suggesting duct tape and baling wire, the "easy way" that will come back to haunt you. Figure out which. That person should probably be either promoted or fired, depending on whether their "simpler ways" are actually correct and robust or not.
A developer's peers will generally know whether they provide good value or not. When preparing to do a performance review of a developer, ask for feedback about that developer from other developers on the team (and other co-workers they interact with on other teams).
Reply to This
You can always blame the implementation.
The classic apologist response is 'you're doing it wrong'.
If a developer is not designing and desk checking a design first before starting to code then they're not doing a good job, even if they believe they're skillful enough not to do so.
The answer to, "How do you know a developer is doing a good job?", is this mysterious creature called a "manager".
If the "managers" are themselves doing a good job, that is.
I think the mania for non-subjective metrics is unhelpful. I could blow smoke up your skirt about function points, adherence to standards, defect rates and all that. The truth is, no one yet has developed really solid, non-gameable, objective metrics for programmer productivity, assessment of skills, maintainability of work product, quality of documentation, code maturity, acceptable performance, and all the rest.
I am a developer and I view my work like authoring essays or books. No one is really going to know the quality of my stuff unless they read it. Now turn the problem on it's head. Imagine an objective set of metrics for Dostoyevsky, or Shakespeare, or Atwood. Sure, you could come up with some if you had to, but are they useful substitutes for reading the work? No, not even close.
That's the problem right there. It often feels to me like companies these days, they don't trust their own managers. They keep trying to find metrics, or algorithms, or simple objective tests, to substitute for the qualities a good manager used to have. "Why, the trend line in Google Analytics for Production Unit 83592 is going below the KPI threshold! Call HR!"
Or how about just talking to Frank, who is Production Un-er, Sally's manager. He'll tell you. "Yes, Sally had a late night out with friends last night and she's suffering the consequences. Leave her alone, she'll be fine by tomorrow."
Sometimes the most productive and useful people are not the ones meeting arbitrary deadlines for ill-defend output.
I would summarize this as - are people giving you what you need instead of what you asked for. That is a good programmer.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Is the head of the IT interested in getting things done? And that goes down the line. Fish rot from the head.
Any "measurable" metric can be and will be gamed. Its a waste of time, and counterproductive. Stop trying to find a magic number, it doesn't exist. Instead look at relative levels of respect by their coworkers, and whether they get what they say they will done (what they say, not what they're told to do).
I still have more fans than freaks. WTF is wrong with you people?
Measure the developer based upon the number of features that are delivered. Measure the bugs of bugs. Take too long to meet schedules then fire them
Peer reviews. Rotate who works with each other and have everyone review each other.
The idiot programmers cause more work for all the other guys, so their review ratings will be lower. At least that's the theory.
The first-level manager should be knowledgeable enough about the development being performed to know good and bad code.
Looking for "productive" programmers is a red herring. Just because someone writes 20K SLOCs of crap code, doesn't mean that same functionality couldn't be done by using a well-tested library and 200 SLOCs of custom code.
Another answer is to let the QA department provide the answer. Every feature or bug goes into the code under a specific CM number. The QA team tests under that same number and reports bugs. Bugs per developer shows how much time a dev wastes for other people - effectively double or triple whatever is really needed. I've worked places where the devs basically added zero bugs (I'm serious) and I've worked places where 2 devs out of a team of 10 added 80% of the bugs. 1 guy would introduce 2 bugs when he was working on another bug to be closed that he introduced. Seems he had a need to check the "complete" box when it wasn't.
The real goal should be to get the most bug free software in the least lines of code that other developers can maintain long term. So - with those 3 criteria, how do you reward devs that accomplish that and have those who cannot choose to leave? Peer pressure. It actually works really well, provided anyone on the team really wants to do a good job.
Each time you introduce metrics to evaluate people, that will distract them from their job in order to improve the metrics.
In other words, you ruin your business by trying to measure how people work. The alternative is to trust employees for doing their job correctly, and to know well enough what they are doing so that you can identify what is wrong when there is a real problem. Of course that requires experience/
As one of those crazy talented developers I'd say that you must be careful with any generalized metrics. Sometimes people forget that no matter what happens it only takes one correct answer to steer a room full of 30 people the right direction.
I've found incredible things that entire teams have done in my absence... then I return and find that I can deliver the final result of what that team of 30 people just spent the last week working on without doing all that work. That is my value..... and yes I expect to be compensated more than those 30 people.
To generalize it's similar to watching a whole group of people wander around in a dark room trying to find something..... the senior developer sees this and from experience knows where a hidden light switch is immediately saving everyone from hours of pain. No amount of extra head count speeds up the solution but a single highly skilled headcount is all that's required.
Knowing this a person like myself also doesn't expect to work as hard as everyone else at grunt work.... I'll come in late and leave early because I know in my mind no other soul in the building can chew through a problem as fast or accurately as myself and you will all be begging next time my services are needed.
As you try to "have your cake and eat it too" by telling me that my advanced skill is no excuse for a bad work ethic, I'll promptly move to helping your competitor and help them otherwise quit both jobs and contract out my services as an LLC. I.E. you won't win I am more powerful and you must appease me and let me do what I want or you won't get the advanced skills I obtained specifically to not be a regular worker bee.
-Signed, a developer who earned over $250,000 last year in a non-big city.
meets the deadline with code that meets specs and QC. Anything else is fluff.
"Consensus" in science is _always_ a political construct.
and being an good, experienced developer.
This is one of the great diseases of the industry - non-technical management, making technical evaluations and decisions.
If you have to ask, just stop. Stop right now and get someone competent to do it for you.