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?
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!
When he can keep deadlines within reason and deliver something that runs pretty well based on the specifications. Anything else is fluff.
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.
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
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.
- Bill Gates
-Dave
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.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
There is plenty of evidence out there as to how long it takes a succesful company to release a piece of software - find something with a similar scale to what you're doing and see how rapidly they release.
Like all the other measures, it's not that simple. Is it code that the development team wrote themselves or did they inherit it? If they inherited it, how well was it originally designed, coded, and documented? Is the project using the best tools for the job or has it been forced to work around suboptimal tools for various reasons? Does the project have a solid design/direction or is the whole thing made up as it goes along? Are there defined use cases the developers can work against? Is there a clear customer stake that the developer can work with to better understand the needs and adjust the code accordingly? Do they keep getting distracted from the deliverable by support or tasks that should be outside their scope?
There are many reasons a good developer may be "under performing" through no fault of their own. Measures like lines of code, bugs, delivery time, etc.. rarely take that into account.
No, stupid. Pay enough to get sufficiently competent people from the marketplace in the first place. People with a track record of leadership in software development sufficient to command good pay because they do a good job. Many companies fail at this, pay below competitive levels and just fill their senior jobs with junior/mid-level staff then wonder why their software development department isn't competitive.
Of course throwing money at someone who is incompetent wont magically make them competent, why would anyone ever think that would be the case?
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Ah yes, 4GL... where you eliminate the easiest part of what a developer does (write code), make the most difficult part (specifying what it should do) harder and make it the responsibility of people who can't even grasp the easy part.
And as soon as you want to do something the 4GL language isn't designed for, your only option is porting it to a 3GL (or lower-level) language.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
That's precisely why you need to find a similar case, or ideally, many similar cases.
How are you supposed to know the intricate details of another company's codebase and development process to be able to judge if they are really similar or not? You can only guess and hanging someone's job on a guess is pretty crappy.
In terms of distractions, if you're in a lead development role then it's your responsibility to raise at the highest levels of management and evidence the fact that your team just isn't being given sufficient time to work on actually writing software and documenting interruptions as evidence isn't difficult. Similarly taking a poor specification up the chain and explaining why it's poor also isn't difficult - explaining where there are deficiencies in a specification is fairly easy to do if they are present. These are all traits in a good lead, and any lead not able to do these things is precisely the sort of junior to mid-level developed wedged into a senior role that I talked about - a good lead has to know how to get things done in the business world as much as they know development.
And how many times have we done just that and heard "we hear you, but ..."? I've spent my career jumping into shit projects and making them maintainable and extendable. Luckily I've mostly had managers that understood what I did for them and trusted me, but I've had a few that haven't and those jobs are miserable because they try to grade me like you suggest and it's unrealistic. I fix code and I make users happy (because I fix the code and simplify their interactions), but that all costs time and pain and management typically just sees "not much movement".
But most of these issues aren't about measuring developer competence, they're about tackling fundamental problems within a business - that's a separate issue.
It's not a separate issue as it directly impacts how efficient a developer can be. Until those issues are addressed (and they never will be) you can't fairly judge anyone on metrics impacted by those issues.
If you can't tackle those then you're fucked as a business regardless of how good or bad your developers are.
Welcome to the world of a real job working for a real company. Most companies have fucked up processes and policies.
I was pretty much thinking of that code. I once has a coworker like that. I remember that one time he got called in during his days off, he looked like he just came from some kind of drug party (and probably did), staggered to his seat, dumped half the coffee all over his shirt, fixed the problem, was told that he can go home now and replied "Sounds too elaborate" before simply sleeping at the desk.
And yes, he was sleeping. And snoring.
Such people exist. I have met a few that are like that, not THAT extreme but some rather odd fellows with odd quirks do exist. Funny enough, you can't motivate them with money. But they are easily motivated by allowing them to live out their particular brand of insanity.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Either there are no senior developers that deserve the name, ...
I think that is relative within any organization. I once had a junior software developer, who was just a few months out of college, ask when he would be promoted to "senior engineer". I replied, when you don't need another senior engineer to help you with your work.
Referencing the above, his manager once asked me if an assignment would be too difficult for this junior guy. I replied probably not, but he'll probably need help. I said I would code a working example (that could be used if needed) and mentor the guy through developing his own code. I spent a fair amount of time at the white-boarded over the next 2 weeks helping him work through developing his script. In the end, the junior guy was surprised that I always seemed to have the answers and I told him that I had already written an example program (that actually did more than his). He asked me how long it took me to write the program. I replied 2 hours.
It must have been something you assimilated. . . .