6 ms·

> I once reviewed code for a company that got purchased. I took less than a few hours to reach conclusion. There were 7 developers and in 2 months only one was

• cdavid 4y ago
  LOC produced is a good example of what I call "negative" metric: high value does not mean much, but low value is a good indication that something is up. As a manager, I won't care that dev A produces 2k vs dev B produced 4k. But if I see dev C would produced only 30 loc over say a quarter, something is most likely off.
  • iopq 4y ago
    What if I produced only 30 lines of code and removed 1950 lines of code?
    • xgbi 4y ago
      Maybe the metric should be "How much diff did you produce. Removing 2k LOC and being able to replace it with 30 is kind of great.
      • cdavid 4y ago
        Yes, obviously you would look at number of lines changed. Which is what git reports to you when you do git log --stat and so on.
    • cdavid 4y ago
      In your career, how often have you seen good software engineers whose main contribution was deleting code ? Please take my argument in good faith: I am not looking at evaluating people based on their added LOC. The context is at orgs where I have reason to believe some people are slacking off, and looking for people who do next to nothing. That's much more common than people who magically make everyone more effective by only deleting code.
      • Thews 4y ago
        I've seen a few projects across different organizations where an old dev was bad at copying and pasting code and ignored DRY principles. The projects had almost no refactoring, and the primary goal of a new dev was cleaning up the redundancy to better map things out for better organization of the codebase.
      • jjav 4y ago
        > In your career, how often have you seen good software engineers whose main contribution was deleting code ? Depends on the size and age of the company. In a startup, approximately never since the job is to build something out of nothing. In a large enterprise with decades of codebase history to be optimized, very frequently.
      • iopq 4y ago
        Yes, I have had to clean up a 300,000 LOC codebase and my primary contribution was deleting old code and reusing code we already had I did say I wrote 30 lines of code, which was reusing other code instead of copy-pasting and changing a few things
    • wantoncl 4y ago
      Hi Bill! https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
    • deleted 4y ago
      [deleted]
    • morelisp 4y ago
      If this is what you did all quarter (and don't have any other artifacts to show, like an ML model or system design or whatever), yes it's a red flag. It's not because the ratio is bad - if you wrote 300 and removed 19500 that might be fine. It's just that 30 is, in an absolute sense, too low.
      • iopq 4y ago
        I had to read 300,000 lines of code first. It's impossible to do that in a week or two. The number of lines removed I don't remember and it changes nothing about the effort to read and understand the whole codebase
        • morelisp 4y ago
          No, this ratio is unrealistic. Either you're making numbers up rather than describing a real situation, or yes you're far too slow for me to want to hire you.
          • iopq 4y ago
            Reading code takes time, have you ever read through an entire 300k LOC codebase ever? That's more lines of code than https://www.gnu.org/software/bash/ https://www.gnu.org/software/bash/
    • d1sxeyes 4y ago
      I don't think anyone (sensible) thinks 'if someone only writes 30 lines of code per quarter, they should be immediately fired'. I think the point is more that if you have someone who's only written 30 lines of code, it's worth taking a look to see what they've been doing instead. For sure there may be a thousand good reasons for it, but as a quick heuristic for 'who is worth having a quick check to see if we're getting the value out of them that we're paying them for?', I don't think it's irrational.
    • mseidl 4y ago
      There was a funny story I don't remember where... A manager was doing LOC as a metric, and they were required to count it. But an engineer refactored and put -1000. That was the last time they asked for it.
  • pclmulqdq 4y ago
    At some point, the curve definitely bends negative. I used to work on a team adjacent to one of the most "productive" programmers at G by that metric. My team, and at least 4 other surrounding teams, had one full-time SWE cleaning up after him. He would go around making changes assuming things that he thought were safe and breaking tests, then his manager would argue with you that because you didn't make a promise that what he did wasn't safe, you have to fix the test breakage.
    • cdavid 4y ago
      Yes, there are large negative externalities to a certain type of engineers who write a lot of code of dubious quality. Even after ignoring all the trivial cases of "artificial code stuffing", etc. I used to work in a very dysfunctional org where the main "architect" was writing lots of broken code that kinda works, and the 20+ people in the team around it would basically be full time in fire fighting mode. The architect was a very smart guy but ironically enough without any sense of architecture: his level of abstraction for network was pushing bytes through a pipe, and for loops for calculations.
      • pclmulqdq 4y ago
        That was similar to this guy - he was a good IC who ended up being over-promoted to an "architecture" role (L7). He didn't really know how to architect things, so he went for creating externalities while resurrecting old, dead projects that past people had designed for him.
• ZeKK14 4y ago
  This is also a sign that code reviews are not working properly (either missing due to a team too small; or not enough time invested to do them properly; or people are not "free" enough to tell their coworker that their code is bad; or it was done too late, once there isn't enough time to fix it; etc). That's mostly an organisation failure.
  • morelisp 4y ago
    Or code reviews are working fine but there are no long-term consequence for people whose code consistently takes 10x more revision after reviewing. (This is also a kind of organizational failure, but one where reprimanding the IC in question can still be the right response. But I also doubt a drive-by ad hoc external review of every person in the company is going to be the best approach to find this!)
• yonaguska 4y ago
  I'm finally working directly with one of these developers. Thankfully he is leaving next week on his own volition. My work load has doubled over the past several weeks due to rewriting most of his code. And needing to extensively vet code that he's still submitting. The worst part is that he's reasonably productive at producing lines and lines of code that barely function.
  • manishsharan 4y ago
    I am curious. Does your organization not use TDD ? How would the code be allowed to marge without running your test suite ? In my experience, I have found it is more productive to coach and mentor developers to adapt TDD and DevOps practices than to vet their code. Instead of vetting their code, I would incorporate statistical code analysis and vulnerability analysis into the build system.
    • lawn 4y ago
      If you churn out new code and features, your test suite will be of very little help if any. If you're also the one responsible for writing tests, you can easily churn out even more unmaintainable crap. In my experience it's not enough to just have them do TDD, because writing a good test suite is hard.
      • turtleyacht 4y ago
        Mutation testing can help evaluate the quality of a test suite. The application code is automatically tweaked and tests run. If a mutant is not "killed," then additional tests may be needed.
    • morelisp 4y ago
      > coach and mentor developers [rather than] vet their code. How do you teach these things concretely without discussing specific code? How do you tell if the lessons are sticking without checking their future work? Aside from that, neither TDD nor DevOps practices will get you idiomatic (relative to internally and externally) code, documentation, non-requirement performance worth a damn, test suites that are any good to begin with, etc. etc.. If you're running through a backlog of CRUD-ish features or whatever maybe those don't matter, though then I also wonder why the need for TDD instead of just a good CI pipeline.
• cad1 4y ago
  “Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” ― John Ousterhout, A Philosophy of Software Design
  • TrueSlacker0 4y ago
    I remember reading somewhere people can be broken down into 3 types. It applies in programming as well as in a restaurant kitchen or your family's garage cleanup. *I'm probably remembering everything wrong but it was something like: Cowboy: move fast and break things style. Sorta what you mentioned above. Duct tape: most people are a form of this. Work on something just long enough to get it working but it's not beautiful and not prepared for the future or edge cases. Professor: these get very little done because of the amount of planning put in and tend to over think most things. But almost never have to come back to a job since it's done properly and to completion. Any team without a blend or with too many cowboys or professors is going to have a tough time.
  • csomar 4y ago
    That's why I refuse to touch code made by these tactical tornado. It's simple, you'll get all the blame, and none of the recognition. Anyone who is in that situation: Don't it even if it means you'll get fired. You'll get fired anyway. The only exception is, if management come to understand what went wrong there and how it should be done. The chances of that are very slim, however.
  • ziml77 4y ago
    This lines up with my experience. The person making constant "tactical" changes looks super productive. But they just deferred the productivity cost. You end up continuing to deal with their fragile mess for the rest of the lifetime of the product. I fully understand that there are circumstances where true tactical changes do make sense, but the tradeoffs should be considered up front.
• deleted 4y ago
  [deleted]