Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

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?
This discussion has been archived. No new comments can be posted.

Slashdot Asks: How Do You Know a Developer is Doing a Good Job?

Comments Filter:
  • by Big Hairy Ian ( 1155547 ) on Friday February 10, 2017 @10:01AM (#53838655)
    When the coffee machine runs out :D
    • Re:Coffee (Score:4, Insightful)

      by Xest ( 935314 ) on Friday February 10, 2017 @10:18AM (#53838789)

      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)

        by iamgnat ( 1015755 ) on Friday February 10, 2017 @10:46AM (#53838997)

        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.

        • by Xest ( 935314 )

          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)

            by iamgnat ( 1015755 ) on Friday February 10, 2017 @11:22AM (#53839305)

            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.

            • by Xest ( 935314 )

              "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)

        by gweihir ( 88907 ) on Friday February 10, 2017 @10:48AM (#53839013)

        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.

        • by Xest ( 935314 )

          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)

          by fahrbot-bot ( 874524 ) on Friday February 10, 2017 @01:14PM (#53840351)

          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)

        by mwvdlee ( 775178 ) on Friday February 10, 2017 @10:52AM (#53839059) Homepage

        "Senior" in most companies literally means whoever worked there longest.
        It says nothing about abilities or quality.

        • by Xest ( 935314 )

          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

      • Well, the first ones to weed out are the ones "better" than you. But all joking aside. The theory x ass hat parent of this article is looking for new excuses.
    • 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.

      • by gweihir ( 88907 )

        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)

    by the_Bionic_lemming ( 446569 ) on Friday February 10, 2017 @10:04AM (#53838679)

    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.

    • But like someone already pointed out [], 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.

      • I'd be quite surprised if this is really the case. Fixing bugs is inherently harder than not introducing them in the first place, because in the latter case you're having to pay more attention to the code that you're writing and in the former you have to hunt for an issue over the entire codebase. The only time that rushing will save money in the long run is if there's a big advantage in being first to market, even if it's with a substandard product.
    • 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

  • by Anonymous Coward on Friday February 10, 2017 @10:04AM (#53838687)

    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.

  • Deadlines (Score:5, Insightful)

    by Quakeulf ( 2650167 ) on Friday February 10, 2017 @10:08AM (#53838719)
    When he can keep deadlines within reason and deliver something that runs pretty well based on the specifications. Anything else is fluff.
    • Re:Deadlines (Score:5, Insightful)

      by computational super ( 740265 ) on Friday February 10, 2017 @01:09PM (#53840293)

      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.

  • We have this on guy who we wanted to dump as he just did not file them the right way But he just got pushed up to management. And they one of older guys who got layed off burned the office down.

  • When he hasn't murdered the management asking if he is doing a good job....

  • by nimbius ( 983462 ) on Friday February 10, 2017 @10:11AM (#53838743) Homepage
    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.
    • by Anonymous Coward

      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

      • by Verdatum ( 1257828 ) on Friday February 10, 2017 @12:04PM (#53839693)
        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.
      • by nitehawk214 ( 222219 ) on Friday February 10, 2017 @12:31PM (#53839937)

        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.

      • > 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 [].

    • This sounds like a classic case of doing Scrum wrong. The Scrum process has one informal meeting a day of only around 6 people that should never take longer than 10 minutes, one planning meeting at the start of every sprint (two or three weeks), and one demo/retrospective meeting at the end of every sprint. The entire point of Scrum is to kill off "hour long meetings that could've been done in minutes via email" and allow coders to code.

      Standup is "Yesterday I did story 289, users will be able to customiz

    • I work with an offshore team and there was a 3 month backlog when I took over. We have one less person now and backlog is non-existent after I implement a daily 'scrum' (just a call) to go over tickets. We have started taking over work from other teams. I don't buy into agile necessarily but checking in every day for a few minutes really does seem to help.
  • Simple (Score:5, Funny)

    by bickerdyke ( 670000 ) on Friday February 10, 2017 @10:16AM (#53838775)

    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)

    by bigdavex ( 155746 ) on Friday February 10, 2017 @10:19AM (#53838793)

    One of the easiest ways to evaluate a developer is keeping a tab on the amount of value they provide to a business.

    That's easy? OK, problem solved.

    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

    Wait, it's not easy?

    • by mwvdlee ( 775178 )

      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)

    by lazarus ( 2879 ) on Friday February 10, 2017 @10:24AM (#53838841) Homepage Journal

    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.

    • My coworker and I were just talking about this yesterday as our group is doing their annual reviews. We came up with the following:
      • DON'T try to find some one-size-fits-all measurement to judge folks by. It's impossible to find a way to compare back-end and front-end developers that is fair to everyone. If the problem space is different, recognize that.
      • DON'T attempt to find some numeric rating scale. Yes, there are a lot of companies out there that do it, but the numbers are completely arbitrary and mostly
    • A good manager on a software project is an amazing thing. And exactly, gauging a developer's performance is an important part of the job and no trivial task. The best managers have plenty of experience writing code, plenty of experience with higher level theory of software engineering and architecture, plenty of education in general management, and plenty of education in software project-management.

      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)

    by bigdavex ( 155746 ) on Friday February 10, 2017 @10:28AM (#53838859)

    Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

    - Bill Gates

  • Some methods I use (Score:5, Interesting)

    by CastrTroy ( 595695 ) on Friday February 10, 2017 @10:30AM (#53838879) Homepage

    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)

      by Anonymous Coward

      "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

    • by lordmage ( 124376 ) on Friday February 10, 2017 @12:59PM (#53840199) Homepage

      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 (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

    • 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."

  • 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 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

  • by gweihir ( 88907 ) on Friday February 10, 2017 @10:38AM (#53838949)

    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.

  • "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."

  • ...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.

  • I think it's a really hard thing to quantify a 'good job' for a developer? The amount of context and work scenarios would make your head explode, honestly.

    What if we were talking a one to two developer shop where hackish amateurism and 5-minute produced Wordpress sites seems like 'magic' and just 'works'? On the complete other side of the spectrum with your Google, Facebook, Amazon, Snapchat, Instagram, and Microsoft's of the world in terms of fixing an ultra complex situation in 5 minutes that's nearly b

  • by ( 3412475 ) on Friday February 10, 2017 @11:03AM (#53839149)

    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 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.

  • 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

  • Without reading through any of the comments, I predict that 90% of them will be "the only good developer is me, everybody else is an idiot".
  • I once worked for a startup and I was very productive. I build two new products from a remote location for the company that resulted in tens of $Millions in new sales. I would work all day from a quiet place all by myself (no meetings, interruptions, etc.). A few years later, the company changed management and they wanted to 'cut the fat' from development. I happened to be working part-time at the time (recovering from burn-out) but was still very productive. It didn't matter at all to those bean counters t
  • 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

  • by Murdoch5 ( 1563847 ) on Friday February 10, 2017 @11:49AM (#53839549)
    It's a multi-state, multi-variable issue and depends what kind of development the developer is doing.

    As an example, when I'm doing low ever firmware development, things I would measure as success:
    1. Robustness of solution.
    2. Efficiency of Code.
    3. Preform a LINT / leak scanner and look at that output.
    4. Speed of module / driver / support coding.
    5. How they handle library and portability in their development.
    6. Security and complexity in terms of O and o.

    Web Frontend Development:
    1. How their work scales across different browsers and resolutions.
    2. Engagment, look and feel.
    3. Lines of code to implement certain aspects, less (usually) better.
    4. Framework engagement, for instance using Angular.JS instead of rolling their own.
    5. Knowing / applying stuff like jQuery or knowing not to.
    6. How they implement REST services.

    If I'm doing Server End work, I'll have a completely different set of requirements, same with desktop frontend, backend and etc....
  • Feature importance * lines of code / CPU time required to run code = score
  • Not that difficult if your developers work off a bug and feature log. The managers should assign bugs and features to the developers, and over time the daily average of bugs successfully closed, or features accepted for a build per day is a pretty good metric. I don't think it is hard if you have good processes and track everything with a bug and feature log.
  • Every time a "serious" defect is found, figure out who is to blame. It will usually be the person who wrote the code, but may not always be that person. For instance, if he or she relied on behavior from someone else's code that was falsely advertised. Or if he was given inadequate requirements. If a particular developer is disproportionately frequently to blame for major problems, then that person probably isn't a good developer. Also take into account total output and "sensitivity" of what someone's
  • 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

  • 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

panic: kernel trap (ignored)