Slashdot Asks: How Do You Know a Developer is Doing a Good Job? 229
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?
Coffee (Score:3)
Re:Coffee (Score:4, Insightful)
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.
Re:Coffee (Score:5, Insightful)
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.
Re: (Score:2)
That's precisely why you need to find a similar case, or ideally, many similar cases.
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 whe
Re:Coffee (Score:5, Insightful)
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.
Re: (Score:2)
"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."
I don't think the intricate details matter, I've worked for enough different companies to realise that the idea that some company is a special snowflake is an incredibly rare an unlikely thing. The odds of your company being in such a fundamentally different place that you're
Re:Coffee (Score:5, Insightful)
From what I have seen in the industry, it is very simple: Either there are no senior developers that deserve the name, or they are not asked on anything that is "management".
I fully agree with you. The job to evaluate technological skills must always be done by a chief engineer (or equivalent). If you do not have a chief engineer, then you cannot evaluate the technological skills of people, and that is it. Other engineering disciplines do understand this. But "coders" are often not even viewed as engineers these days, which is just plain stupid and just another facet of the same problem.
Re: (Score:2)
I think I've always been quite lucky in that respect, whether working at small companies or large, public sector or private, I've always found that development's opinion has at least been deeply respected. We've always been recognised as the money makers so there's always been an inherent fear about interfering with us unnecessarily.
I wonder what the difference is? I've worked as a developer in a few fields - engineering, defence, medical, and finance so I don't think it's a field specific issue. Maybe cult
Re:Coffee (Score:5, Interesting)
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.
Re:Coffee (Score:4, Insightful)
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.
Re:Coffee (Score:4, Insightful)
"Senior" in most companies literally means whoever worked there longest.
It says nothing about abilities or quality.
Re: (Score:3)
I don't disagree, I think this is where the problem with most companies struggling with development is - they just don't have the talent sufficient to judge whether they have the talent.
Time and time again the companies that I've seen excel at development have either found a 1 in 100 developer out of sheer damn luck who just happened to be looking for some aspect of the role in question (i.e. maybe it's a small town and they just wanted to live near their family regardless of career impact), or they've deci
Re: (Score:2)
Re:Coffee (Score:5, Insightful)
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?
Re: (Score:2)
No, I think someone's skill is based on how succesful they are at doing the job as demonstrated by their track record. What they tell you is irrelevant, what they've done, and what can be backed up by research, references, and a competent interview process is really what matters.
"In bumfuck, USA, there is nothing but small developers, even the ones that charge 6 figures."
I've no doubt, but how is having an effective way to measure competence going to help that? If you don't have the local talent available y
Re: (Score:3)
The problems you must be having in this industry to be so angry about this topic might be because you don't take criticism well.
Not sure what gives me that impression but you know, just saying.
Re: (Score:2)
When the coffee machine runs out :D
There's no 'metric' that can't be gamed. If I was being paid to drink coffee I'd be emptying it into secret buckets.
Re: (Score:2)
Indeed. Trying to come up with metrics that people whose primary skill is analytic and secondary main skill is coming up with procedures cannot game is about the most stupid thing possible.
In my experience (Score:5, Insightful)
Judge them on bugs. If they are constantly trying to fix their code then you have a metric on when to seek a better one.
Re: (Score:2)
But like someone already pointed out [slashdot.org], this metric is trivially gamed.
If I spent twice as long on each feature, I'd be able to reduce my bug-count, but I would probably be unduly costing my employer in the process.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
Are they their bugs or someone else's? Are they due to inherited code that was poorly designed and even more poorly documented? Are they because something was forced into a design/architecture that couldn't support it? Are they due to bad tools/frameworks being used (through no fault of the developer in question)? What's a bug versus an unclear/unknown requirement?
As far as seeking a better one, just how in the process of interviewing someone (even in one of those drawn out all day BS games that are favored
Re:In my experience (Score:5, Insightful)
Juniors write code, seniors fix bugs.
That's my approach to that problem at least. And so far I've been doing great with it.
90% of code is trivial bullshit. Anyone can do it, hell, even cargo-cult programming cannot fuck it up. Sitting a senior programmer down to do that is a waste of resources.
10% of code is insanely difficult to figure out, arcane mystical bullshit. Hard to write, hard to maintain, hard to understand and even harder to get right.
You could now either spend time and resources trying to identify those 10%... or you could simply hand the whole jobs of "coloring in your code" to the juniors, watch where they struggle and then set your cracks onto those problems. That serves many purposes.
You eliminate the need to identify those cases.
Your juniors feel valued because they get to work on nontrivial tasks.
It's a very good indicator which of your juniors are really GOOD at their job (hint: The ones that don't ask for help AND still deliver in those 10% cases),
You can keep the amount of high value (and wage) programmers relatively low.
You don't bore your crack programmers with trivial tasks you misidentified as nontrivial.
There is an implicit knowledge transfer from senior to junior
And so on.
That does NOT eliminate the need for good code design, actually, having a good design phase is absolutely crucial to this approach, since else your juniors have to design. That would be ... let's say sub-optimal. You have to give them the outline picture and have them connect the dot and color it in, so to speak.
Re:In my experience (Score:4, Insightful)
Juniors write code, seniors fix bugs.
I'd expect experienced developers to run like hell from that situation. Who wants to spend the majority of their time cleaning up rookie developers' crap?!
Re: (Score:3)
Re:In my experience (Score:4, Insightful)
If your junior developers are writing all the new code, they will be causing deep seated flaws that cause your senior developers to perpetually fight fires.
Re:In my experience (Score:4, Insightful)
That's why code design is separate from code implementation.
Yes, I know it got unfashionable, but there's a reason why that used to be two different steps in the production process.
Good. Also specialization and heuristics (Score:4, Interesting)
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.
Re: (Score:2)
Most of what you wrote resonates with me, but the bit about organization of files could use some elaboration.
A single source code file can work well for many small projects, if the code within that file is well-organized. Meanwhile, spreading a project across multiple files and directories can be done to excess, and become an unwieldy nightmare pretty quickly. (Most Java projects I've seen are in the latter category, in no small part because the language encourages it.) A wilderness of files and directories
Agreed, though even small projects grow (Score:2)
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
Forgot the footnote (Score:2)
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
Re:In my experience (Score:5, Insightful)
That sort of seems backwards. It is a hell of a lot easier and quicker to not program a bug in the first place, than to find and fix one. Anyone can code, sure, but if you plan on eventfully delivering a bug free program, maybe the poor coders writing poor bug filled code are not really helping with this at all. Perhaps the senior coders, could have written a better functioning, and easier to maintain piece of software alone, way easier than trying to transform a trash-heap of code into something usable.
Re: (Score:2, Insightful)
Run.
Who in their sane mind sends juniors bug hunting? Especially fresh hires, they're busy enough trying to get to terms with the SVN setup and most likely they are new to the toolchain or at least part of it, too. How the FUCK should these people be qualified to find bugs? They don't even know whether the problem is related to code or the environment.
Run, run far away from jobs like that.
Re:In my experience (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
This has a problem that if the bug is intentionally left there for somebody else to fix then it may be easy enough for another developer other than the one you are cooperating with to fix, so the person you are cooperating with may not get these easy bugs that you leave, and may thus not have any incentive to leave any for you. Further, intentionally leaving bugs in the code might also scream that you do not perform even the most basic rudimentary testing on your code before submitting it into the compa
Hint: It ain't the guy called in all the time (Score:3, Insightful)
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.
Re:Hint: It ain't the guy called in all the time (Score:5, Insightful)
Don't confuse him with the guy that you call at 3am who staggers in drunk and baked, sits down at the terminal and just before passing out and throwing up on the carpet at 3:15am returns your system to a running state despite the problem being in an area he has never worked in nor has any connection to.
That guy you should keep.
Re:Hint: It ain't the guy called in all the time (Score:4, Funny)
http://www.commitstrip.com/en/... [commitstrip.com]
Re:Hint: It ain't the guy called in all the time (Score:5, Interesting)
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.
Re: (Score:2)
...thinking of the comic...
Guess I should get some sleep... someone find me a comfy keyboard, could you?
sleeeeep (Score:2)
Yeah, just make sure to shutdown the computer before sleeeeeeeeeeeeeeeeeeee Filter error: Too much repetition.
Re: (Score:2)
Doing the same job for years surely optimizes one's brain for a specific task.
Re: (Score:2)
So basically I should work on as little code as possible, since fixing bugs in any code I ever touched makes me a bad coder?
Deadlines (Score:5, Insightful)
Re:Deadlines (Score:5, Insightful)
After I graduated college and started working, I began to notice a pattern in the jobs I got: I'd start out doing work and producing stuff, and the people around me would start to notice that I was good at doing work and producing stuff, and that I seemed to know a lot of stuff (I love to study arcane details like how TCP/IP or SSL work, so I can often troubleshoot unusual problems), so they would start asking for my help. I would help more and more with other things, and spend less and less time doing work and producing stuff. So I'd start to get criticism for not doing work and producing stuff ("on time and under budget, you programmer peon, and if you don't like it there's a hundred guys in India who will do your job for half what I pay you!"), so I'd yo-yo back to turning away requests for help so that I could focus on doing work and producing stuff, only to get criticism for not being a good team player. (Funny how "team work makes the dream work" but we're evaluated only on our own individual accomplishments)
Since being a good team player is the polar opposite of adhering to arbitrary deadlines, I've experimented both ways over the past 25 years and I've come to the conclusion that being ready and willing to drop everything and helping out whoever needs or asks for your help is what makes you "valuable", not slavishly adhering to meaningless deadlines, regardless of how you think the world ought to work.
Re: (Score:2)
TPS reports! (Score:2)
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.
easy.... (Score:2)
When he hasn't murdered the management asking if he is doing a good job....
Re: (Score:2)
...he's not, because he has shown he cannot identify things that lower his productivity.
Re: (Score:2)
But he has. He even prevented the issue from causing future loss of productivity.
Re: (Score:2)
How? He hasn't murdered management.
Comment removed (Score:5, Insightful)
Please explain the point of SCRUM/Kanban... (Score:2, Interesting)
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
Re:Please explain the point of SCRUM/Kanban... (Score:4, Informative)
Re:Please explain the point of SCRUM/Kanban... (Score:4, Insightful)
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.
Re: (Score:2)
> and the 3-4 hour physical "stand up" meetings daily
Holy shit! No wonder you bitch about SCRUMM. You're doing it wrong.
Standup meetings shoot take between 5 and 10 minutes; 15 minutes MAX. It is supposed to be a "macro" view -- not a deep dive into the micro-issues. Anything else should be taken "offline."
--
Slashtard, Redditard, noun, an imbecile who down-votes everything they disagree. When you stop being challenged, you stop learning [youtu.be].
Re: (Score:3)
Standup is "Yesterday I did story 289, users will be able to customiz
Re: (Score:2)
Simple (Score:5, Funny)
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 :-)
Wait, what? (Score:4, Interesting)
That's easy? OK, problem solved.
Wait, it's not easy?
Re: (Score:2)
That's easy to fix; just make it easy to measure the value a single developer brings.
Now please hand me my management bachelors' degree.
Management Is Hard (Score:5, Insightful)
So this comes down to actually being a good manager. It's hard, and lots of people do it wrong / pretend they are good but aren't / etc. Ask yourself what you really want in a developer and then manage your team to that standard understanding that each member has their own strengths and weaknesses. Something like:
- Elegant and easily understood code
- Good at estimating and meeting deadlines
- Productive and participative in scrums
- Thoughtful and supportive of alternative views
- Etc.
Coders are people. They are a unique breed of people, sure, but if you want to gauge their worth, then you manage and treat them like people. Not monkeys at a typewriter. A small group of talented and creative coders can save a company millions in just a day of work. I've seen it. You need to appreciate their value by paying attention, not coming up with some arbitrary metric that makes your job easier.
Re: (Score:2)
Re: (Score:3)
A bad manager is usually an electrical engineer who has many years of seniority, who got pushed into softwar
Bill Gates said (Score:5, Insightful)
- Bill Gates
Re: (Score:2)
Lines of Code has always been a bullshit metric.
-2000 Lines Of Code [folklore.org]
Some methods I use (Score:5, Interesting)
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.
Re: (Score:2, Insightful)
"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."
I don't know what you do for a living, but I'm a developer, and I frequently say that. Of course I test tasks as I complete them, but what you say implies integration is trivial and requires little to no testing. This is simply
Re:Some methods I use (Score:5, Insightful)
Sigh. This is how great developers see bad managers and avoid them.
1. Defect Rate: The more experience, quality developers are given the more complex tasks generally and actually generate a large amount of defects. Defects are also a case of amount of humanity involved in the area developed. More defects in HMI code because of more eyes. Defects are also based on testing, so if a code is rarely used or testing only cursory, defects are not found. This information can be found and highlighted in the FREE Debugging course from Andreas Zeller at udacity.com (Nope not shilling but found this course very informational).
2. Just because someone is an experienced developer does not mean they can estimate a job. One of the hardest things that developers are asked to do is SWAG a job. The numbers are generally way underestimated due to our human overestimation of time in future (look it up, I dont have the time. heh). These times get filtered back through contracts and customers and come back even less time. Exactly how many projects have you been on that actually made time/budget exactly as estimated? There is a reason developers work a lot of unpaid overtime.
3. Testing as you go along. Are you stating all developers should do Test Driven Development? Okay, then provide hard, frozen requirements up front. Oh wait, you are AGILE so that cant happen for larger items. Oh.. there we go.. inch pebbles.. I think the best estimate is down to 3-4 hour chunks of time. Okay, so I established that ETC is hard enough, now do it constantly in a changing requirements weekly. Wait, Im almost done here.. give me some time to finish... I thought I would be done before lunch.. but Im not done yet. Management responsibility is to manage the developer to help them and the management to make realistic time.. so "almost done" is not done.
- Is it Soup? That is what I heard from my bosses when I first started in the game. Is it Soup? 20 minutes from me being first assigned a task. No real concept of the entire task. You learn to answer "Shortly" and they stop asking. 2 weeks if they ask me now.. no matter what it is. They learned to give me real time to get a much better ETC out. One of my early ETC was "3 months" from spending 2 hours on the ETC. When given 3 days, the ETC was a year and it took... a year!
4. Development and constant need to have stuff explained. Verify they understand the first time. Language barriers exist constantly. Yes, this is a decent enough metric but if they can follow computer language logic, they are not dumb. I am at a place where it is expected for new developers to work 18-24 months before becomes productive. Still.. this is one that I can see if you want to cycle engineers to get better ones and do not have a large learning curve for your products.
5. This is general employee issue. Not specific to developers.
KLOC metrics and defect metrics are shown to have real faults when using them to judge a developer.
Things that managers (or leads, including myself) do that slow down/hurt development:
1. Not listen. Most of the time, as a lead, we know it all BUT we are NOT listening and not HEARING why some task will not come close to what we think will happen in the project.
2. Micro Manage. Start the task with a known stopping date and get buy in. Dont go every to them 4 times a day, put them in a fishbowl, look at your watch if they take a longer lunch or go to a doctor, and tell others you dont trust developers as they need to be lorded over (yes, had a manager do this). The developer will come to you when they realize they have issues or need help. You help them by resources, processes, talking, etc but If you then look at them like they are insane.. you will no longer have that trust and you will have way more "Surprises". Here is a metric: If a developer never needs help and has surprises on time and issues... if you are not micro managing them, this issue lies in the developer and they need help on personal time management s
Re: (Score:2)
You can't test edge cases along the way, especially if they rely on the finished product. Of course actually testing for edge cases before release will make a developer less "productive."
You talk to each other. And *BOTH* listen. (Score:2)
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.
You know by being good yourself (Score:2)
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
Metrics cannot replace understanding (Score:4, Interesting)
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.
Re: (Score:3)
Corporations like Rand sold governments and corporations on the idea that you can mathematically model people and their worth. The world has been going downhill ever since. https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
oh, just realized the video is on youtube: https://www.youtube.com/watch?... [youtube.com]
Translation (Score:2)
"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."
If you ant to evaluate a developer... (Score:2)
...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.
Re: (Score:2)
Big teams vs small teams (Score:4, Interesting)
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.
Re: (Score:3)
I stopped reading at "agile". Buzz words put me to sleep even with the amount of coffee I've consumed this morning. Fortunately, "power naps" increase the readability and "weight" of my code.
Holism (Score:2)
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 a
I know (Score:2)
How to weed out your best programmers... (Score:2)
RFC ProgrammersRank (P-Rank) (Score:2)
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
As a Professional Devevloper (Score:3)
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....
Metric (Score:2)
Not that difficult (Score:2)
assign blame for bugs (Score:2)
How to measure a great developer (Score:2)
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 t
Define what actually matters to you (Score:2)
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
Re: (Score:2)
Re:Irrelevant (Score:5, Insightful)
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.
Re: (Score:2)
Ah yes, 4GL.
Actually the Language is irrelevant I know devs who use it to code in Java, C++, C and the current version will do .net out of the box. The 4GL you speak of is just the default because back when it first came onto the scene 4GL's were shiny and new and a lot of folks still maintain legacy apps.
Re:Irrelevant (Score:4, Interesting)
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.
Re: (Score:2)
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?
Are you working on the same code as I am? Sure sounds like it...
The problem with all these metrics is that there are tons of inherited code bases like the one described and now the poor shmucks that have to pick up the pieces are to be held accountable to these metrics when much of it is out of their control (because how often does management bite the bullet and allow for a complete rewrite?). If the code does not allow for extension and the new developer is tasked with extending it, it's going to be slow a
Re: (Score:2)
Agree! And in particular, do the test cases cover both all expected functionality and error situations, particularly bad (user) input?
(someone please mod parent up).