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?
That's easy? OK, problem solved.
Wait, it's not easy?
-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.
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.
Hahahahahaha, good one. I heard this first for the 5GL language project. That one started about 30 years ago and failed miserably more than 20 years ago. This time will not be any different.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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.
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.
I fixed a lot of bugs as a junior developer and try to hand as many as I can to junior guys now, too. Yes, you're throwing them in the deep end of the pool. But understanding that, I've yet to find a better way to learn the ins and out of complex existing systems. Stepping through a debugger shows the execution paths, looking for a bug forces you to read the code _carefully_. Bugs often span neatly defined encapsulations, such that you're figuring out how two disparate systems interact.
Putting a senior developer on it will fix the bug faster, but you'll get new senior developers quicker by forcing junior developers to act like one.
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.
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. . . .