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!
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.
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
Jokes aside I'd argue there's actually a more fundamental question that stems from the question being asked.
Why aren't your senior/lead developers weeding this people out? That's their job, they'll spot bad developers by working with them based on a number of metrics from readability of code, number of bugs, performance, amount of useful code produced and so on, not just a single metric.
If your senior/lead developers aren't doing this then you've probably not paid enough, you've probably paid too little and ended up putting a low to mid level developer in what you've called a senior role.
If it's your senior/lead you're concerned about then you should just be able to go on track record - do they have a history of delivering high quality software in a reasonable timeframe? Are you confused about what a reasonable timeframe is? Look at other software on the market, how long does it take Microsoft to release a new version of Word? Adobe a new version of Acrobat? and so on. 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. If you're paying competitively against those companies, and your developer isn't delivering as rapidly then they're underperforming, if you're not paying as much as they are then don't expect them to be able to produce as much quality in as little time. If they're overperforming in quality and delivery speed and you're paying them less than the big boys then thank yourself that you've found a fucking star and spend a lot of time thanking them for giving you more for less money and do everything you can to make them happy and keep them, because if they leave, you might not be so lucky next time.
That's easy? OK, problem solved.
Wait, it's not easy?
-Dave
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.
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.
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.
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.
"Senior" in most companies literally means whoever worked there longest.
It says nothing about abilities or quality.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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?
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.
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.
Wow. Those guys were doing Scrum completely wrong. A daily standup is intentionally a "standup" because about the time you get tired of standing means the meeting should be long over. A daily standup should be down to about 10 minutes. If it takes longer, your team is either too larger for Scrum, or people are talking about stuff that should be taken offline. So when someone mentions a block, you don't try to fix it or squabble about it, the Scrummaster (yeah, I hate the term) makes a note of it, and you move on. And when the PM tries to fix the problem, it's the scrummaster's job to cut him off immediately. That's why the SM and the PM are two different people.
I don't think that place would have been functional with any methodology.
Though I have noticed that teams where the SCRUM master is a project manager they tend to be filled with useless endless meetings.
When the SCRUM master has a real job like writing code, the meetings are pretty concise.
I was at a non-methodology place that was like yours. The manager has 20 direct reports, and never talked to anyone except in the occasional weekly meeting. Each person would go on a 5 minute spiel as the manager asked a ton of questions while everyone else sat around twiddling their thumbs. I would make sure to say as little as possible because I knew nobody else in the room gave a shit about what I was working on most of the time.
The weekly meeting too so long we started having it once every other week, then once a month. Which of course meant each person had more and more to report.
I'm a good cook. I'm a fantastic eater. - Steven Brust
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. . . .
And for those of us without your patience, watching the junior guys struggle is so painful. I know, I know. They need to learn but can't they learn a little faster? Please.
I always tell more junior people that they need to *some* research when they have a problem, but that this is work not school and if they can't find a solution in a reasonable amount of time (15-30 min), they need to ask someone for assistance. I'll either help point the way, explain and/or provide an example. In addition, I don't mind getting 50 questions, but they need to be 50 *different* questions.
Things to remember: (a) Time is valuable, but my time is more valuable than yours :-) (b) Patience is not an unlimited resource.
It must have been something you assimilated. . . .