14 ms·

I don't at all object to code reviews/evaluation, but the thing I wonder about is this: I rarely open an empty file and write some big block of code. 98% of the

I don't at all object to code reviews/evaluation, but the thing I wonder about is this: I rarely open an empty file and write some big block of code. 98% of the time I'm fixing bugs in legacy code or shimming in some new feature. It would be trivial to produce the diffs I generated in the past 30 or 60 days, but the volume of code isn't really a great metric for my productivity. There may be some three line change that was the result of eight hours of debugging and analyzing how to best fix the bug without disturbing the stuff that is working. Is that more or less productive than someone who cut & pasted a 100 line routine they found via google?

lgleason 4y ago
ttyprintk 4y ago
I work in a regulated sector. If I need to know the priority of a PR, it’s the speed from code review to integration.
deleted 4y ago
[deleted]
asdffdsa 4y ago
Exactly, more code isn't better
- jacob019 4y ago
  Not only that, less code is better. The elegant and performant solution is the simple one, for example wireguard vs openvpn.
  - philliphaydon 4y ago
    Nope. Less code is not always better. Collapsing a loop into a single line lambda with single char variables doing 5 times is not elegant or better. It’s orders of magnitude worse. Less code is more readable. But absolute minimal amount of code can be unreadable.
    - jxf 4y ago
      "Less" doesn't mean "fewer bytes", it means "less complexity". If two ASTs do exactly the same thing, but one is easier to understand and has less structure, that one is probably better.
      - kamaal 4y ago
        Less complex in lots of situations means being explicit, not being too template'y, not being too generic, abstract and writing code that is supposed to be a kind of meta that takes in a config and does several things for several inputs. Writing less complex code in lots of situations just means writing lots of code. Which is diametrically opposite to the original statement of less code being better.
        deleted 4y ago
        [deleted]
        jacob019 4y ago
        Being kind of meta, taking config, and doing several things for several inputs are good examples of ways to reduce the amount of code--when used appropriately. Being explicit reduces code too. Over abstracting and premature optimization can result in bloated spaghetti code.
    - jacob019 4y ago
      By less code I mean less logic, not less characters. Less code generally means less work for the CPU (faster), less surface area for attacks, a smaller codebase that is easier to pick up and work on. When working with sets of numerical data, there are often two or more ways to come up with the desired result. A dumb imperative way, that may involve several loops and stages, or a simple and intelligent way that requires a deeper understanding of the math to implement properly. I've seen pages of slow code reduced to a few simple lines that are performant and easy to grok.
  - shapefrog 4y ago
    0 code is the best then?
    - thwayunion 4y ago
      Yes. At a nonprofit I work with, there was a series of web forms that volunteers had to go through in order to enter a bunch of data. Volunteers have never liked this form, but it was at one point necessary to collect all this data. A decade after those forms were built, it was decided to finally spend some of our (all volunteer) engineering capacity to help streamline the process associate with those forms. So, a junior volunteer comes in, hears the groans about this form, and found out a bunch of this data was already stored in other tables (in the interim smartphones became a thing and customer intake went from completely free form to a self-service signup process). The volunteer writes a bunch of selenium code to pull data out of a few tables and use it to population about 80% of the form fields, leaving volunteers with only 20% of the original work! Some time later the whole thing gets reviewed by an (again, volunteer) old hat staff who were around when the original form sequences was developed. Turns out we no longer needed those 20% of fields, and ofc we already had the data in the other 80%... so all the original form code was deleted, So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context.
      - jason-phillips 4y ago
        > So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context. Bravo.
- geekraver 4y ago
  Quite. Code is a liability. LOC is an utterly idiotic metric of programmer contribution, as it incentivizes increasing liability, over all sorts of other better contributions like good design, more automation, mentoring, customer obsession, etc. (And for those arguing that “but the least amount of lines is not necessarily best”, yes, of course, that can obscure logic; the point isn’t to flip the value of LOC as a metric, the point is to not treat it as a good metric).
cptaj 4y ago
And if you indeed make "more lines!" the guiding metric for developer performance, you're setting yourself up for a world of pain because they will sure as hell find out and start gaming the metric. This will lead to a feedback loop of rising expenses and tech debt.
- idontwantthis 4y ago
  As a Vim user, I’ll happily expand my for loops with just a couple of key presses
  - akomtu 4y ago
    Another technique is "versioning" when instead of fixing a function, you duplicate it and slowly migrate callers of this function to its new version.
  - vimwannabe 4y ago
    How do you do the increments smartly
bpodgursky 4y ago
I think this is true and an big problem when artificially separating the top 10% from the top 20%, or top 1% from top 5%... ... but in practice, I think you will find 0 overlap in raw lines of code produced between the top 10% developers and the bottom 10% developers. Especially at a notoriously unproductive organization like Twitter, the bottom tier simply does nothing. If Musk is trying to cut 60% of the org, he's going to have a problem doing it this way. If he's trying to cut 20%, I honestly don't think it's going to misfire much of the time.
- okay_dude13 4y ago
  > notoriously unproductive Pretty crazy this is the first comment stating the obvious in a forum full of programmers with friends at Twitter. Truly the most bonkers underemployed place. Engineers with debilitating levels of ADHD not taking their meds, doing 2 hours of meetings a week and then spacing out on internal tools no one uses. People who come and complain about harassment and abuse, relentlessly campaigning against their bosses’s priorities from day one, and like hardly making a single commit a week. It’s CRAZY. I have never heard from people paid so much who do bonafide so little. And they’re OBVIOUSLY dysfunctional. You can talk to these employees for 1 minute and realize they need to be fired, it wasn’t necessary to do an analysis. Personally I would close down the non SF offices first. Then I would move the best ads people from NY to SF where they can be bettered monitored. Then it will be fine.
segmondy 4y ago
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 writing code. The entire team but that one developer was fired. Twitter has grown a reputation for being slow and a rest and vest haven. Won't be surprised if they are looking for people not writing code. On a different note, If you're in a large org and all you are doing is fixing bugs, you are doing yourself a disservice and so is the org in the way they are treating you. Unless you are the original author of that code. When people don't fix their own bugs, they tend to repeat it in other places. When people tend to fix code they didn't write nor have the proper context on why the code was written like that, they tend to turn it into a mess. IMHO, Developers should be writing new code and maintaining their own code. Never reward developers by giving them more new code and stopping them from maintenance.
- Areading314 4y ago
  Fixing bugs is part of the job. If you care about the product you work on, you have to fix the bugs and not whine about who originally wrote the code.
  - b4je7d7wb 4y ago
    Sure. But also if all you do is fix bugs, unless they are really hard and complex ones in occasionally new domains it's probably not the best career path. As an example fixing trivial styling, dead links, documentation, flaky tests. Work that is important and has to be done, but not something to drown yourself in. Sometimes it's also better to try to solve the root causes, like use css variables, introduce swagger or a more reliable test framework. You want the engineer who codes themselves out of the job of trivial tickets.
    - Areading314 4y ago
      fixing bugs is more important than trivial stuff like swagger, css variables, or adding new test frameworks. Function over form
WalterBright 4y ago
I love being able to fix a bug with a one line change.
- DeathArrow 4y ago
  I love deleting lines. The more lines I delete, the less bugs.
- tcoff91 4y ago
  The hardest bugs to find are often the ones that can be fixed with a one line change. If you figure out a bug quickly, then you are usually in trouble and have to refactor your codebase to resolve it or introduce an awful hack to fix it.
willio58 4y ago
I 100% object to code reviews in this way. If you have dignity as a developer you’d quit swiftly.
- jxf 4y ago
  My advice to someone earlier in their career would not be to quit, but to make them pay you while you look for your next job if the writing is already on the wall.
  - GolfPopper 4y ago
    Yep. Phone it in while you job hunt, without making it completely obvious that's what you doing. I'd be a little surprised if most twitter devs (and anyone else) who can leave, and aren't personally invested in Twitter, are not already doing this.
    - x86x87 4y ago
      Lol. People have been leaving in large numbers ever since this circus began. The exodus will continue.
- DeathArrow 4y ago
  So having dignity means having a financial loss and be job hunting for some time? Why should someone get punished for having dignity?
  - freejazz 4y ago
    > Why should someone get punished for having dignity? We've got a student of history
eterevsky 4y ago
I don't think the code review involves counting the lines. A reviewer can distinguish hundreds of lines of boilerplate from a non-trivial few lines change.
- seadan83 4y ago
  Agree, I would expect the first question after "what did you change", would be "walk me through the impact of this change"
chromakode 4y ago
"Making chalk mark on generator $1. Knowing where to make mark $9,999." https://www.smithsonianmag.com/history/charles-proteus-steinmetz-the-wizard-of-schenectady-51912022/ https://www.smithsonianmag.com/history/charles-proteus-stein...
smk_ 4y ago
I would imagine this fact is obvious to any Tesla engineers reviewing code. I would imagine they look at more factors than simply lines of code.
deleted 4y ago
[deleted]

lgleason 4y ago

ttyprintk 4y ago

I work in a regulated sector. If I need to know the priority of a PR, it’s the speed from code review to integration.

deleted 4y ago

[deleted]

asdffdsa 4y ago

Exactly, more code isn't better

jacob019 4y ago
Not only that, less code is better. The elegant and performant solution is the simple one, for example wireguard vs openvpn.
- philliphaydon 4y ago
  Nope. Less code is not always better. Collapsing a loop into a single line lambda with single char variables doing 5 times is not elegant or better. It’s orders of magnitude worse. Less code is more readable. But absolute minimal amount of code can be unreadable.
  - jxf 4y ago
    "Less" doesn't mean "fewer bytes", it means "less complexity". If two ASTs do exactly the same thing, but one is easier to understand and has less structure, that one is probably better.
    - kamaal 4y ago
      Less complex in lots of situations means being explicit, not being too template'y, not being too generic, abstract and writing code that is supposed to be a kind of meta that takes in a config and does several things for several inputs. Writing less complex code in lots of situations just means writing lots of code. Which is diametrically opposite to the original statement of less code being better.
      - deleted 4y ago
        [deleted]
      - jacob019 4y ago
        Being kind of meta, taking config, and doing several things for several inputs are good examples of ways to reduce the amount of code--when used appropriately. Being explicit reduces code too. Over abstracting and premature optimization can result in bloated spaghetti code.
  - jacob019 4y ago
    By less code I mean less logic, not less characters. Less code generally means less work for the CPU (faster), less surface area for attacks, a smaller codebase that is easier to pick up and work on. When working with sets of numerical data, there are often two or more ways to come up with the desired result. A dumb imperative way, that may involve several loops and stages, or a simple and intelligent way that requires a deeper understanding of the math to implement properly. I've seen pages of slow code reduced to a few simple lines that are performant and easy to grok.
- shapefrog 4y ago
  0 code is the best then?
  - thwayunion 4y ago
    Yes. At a nonprofit I work with, there was a series of web forms that volunteers had to go through in order to enter a bunch of data. Volunteers have never liked this form, but it was at one point necessary to collect all this data. A decade after those forms were built, it was decided to finally spend some of our (all volunteer) engineering capacity to help streamline the process associate with those forms. So, a junior volunteer comes in, hears the groans about this form, and found out a bunch of this data was already stored in other tables (in the interim smartphones became a thing and customer intake went from completely free form to a self-service signup process). The volunteer writes a bunch of selenium code to pull data out of a few tables and use it to population about 80% of the form fields, leaving volunteers with only 20% of the original work! Some time later the whole thing gets reviewed by an (again, volunteer) old hat staff who were around when the original form sequences was developed. Turns out we no longer needed those 20% of fields, and ofc we already had the data in the other 80%... so all the original form code was deleted, So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context.
    - jason-phillips 4y ago
      > So the forms were retired completely, the selenium code was deleted, and the original problem was solved in a strictly superior way with 0 LOC by understanding the business need and historical context. Bravo.
geekraver 4y ago
Quite. Code is a liability. LOC is an utterly idiotic metric of programmer contribution, as it incentivizes increasing liability, over all sorts of other better contributions like good design, more automation, mentoring, customer obsession, etc. (And for those arguing that “but the least amount of lines is not necessarily best”, yes, of course, that can obscure logic; the point isn’t to flip the value of LOC as a metric, the point is to not treat it as a good metric).

cptaj 4y ago

And if you indeed make "more lines!" the guiding metric for developer performance, you're setting yourself up for a world of pain because they will sure as hell find out and start gaming the metric. This will lead to a feedback loop of rising expenses and tech debt.

idontwantthis 4y ago
As a Vim user, I’ll happily expand my for loops with just a couple of key presses
- akomtu 4y ago
  Another technique is "versioning" when instead of fixing a function, you duplicate it and slowly migrate callers of this function to its new version.
- vimwannabe 4y ago
  How do you do the increments smartly

bpodgursky 4y ago

I think this is true and an big problem when artificially separating the top 10% from the top 20%, or top 1% from top 5%... ... but in practice, I think you will find 0 overlap in raw lines of code produced between the top 10% developers and the bottom 10% developers. Especially at a notoriously unproductive organization like Twitter, the bottom tier simply does nothing. If Musk is trying to cut 60% of the org, he's going to have a problem doing it this way. If he's trying to cut 20%, I honestly don't think it's going to misfire much of the time.

okay_dude13 4y ago
> notoriously unproductive Pretty crazy this is the first comment stating the obvious in a forum full of programmers with friends at Twitter. Truly the most bonkers underemployed place. Engineers with debilitating levels of ADHD not taking their meds, doing 2 hours of meetings a week and then spacing out on internal tools no one uses. People who come and complain about harassment and abuse, relentlessly campaigning against their bosses’s priorities from day one, and like hardly making a single commit a week. It’s CRAZY. I have never heard from people paid so much who do bonafide so little. And they’re OBVIOUSLY dysfunctional. You can talk to these employees for 1 minute and realize they need to be fired, it wasn’t necessary to do an analysis. Personally I would close down the non SF offices first. Then I would move the best ads people from NY to SF where they can be bettered monitored. Then it will be fine.

segmondy 4y ago

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 writing code. The entire team but that one developer was fired. Twitter has grown a reputation for being slow and a rest and vest haven. Won't be surprised if they are looking for people not writing code. On a different note, If you're in a large org and all you are doing is fixing bugs, you are doing yourself a disservice and so is the org in the way they are treating you. Unless you are the original author of that code. When people don't fix their own bugs, they tend to repeat it in other places. When people tend to fix code they didn't write nor have the proper context on why the code was written like that, they tend to turn it into a mess. IMHO, Developers should be writing new code and maintaining their own code. Never reward developers by giving them more new code and stopping them from maintenance.

Areading314 4y ago
Fixing bugs is part of the job. If you care about the product you work on, you have to fix the bugs and not whine about who originally wrote the code.
- b4je7d7wb 4y ago
  Sure. But also if all you do is fix bugs, unless they are really hard and complex ones in occasionally new domains it's probably not the best career path. As an example fixing trivial styling, dead links, documentation, flaky tests. Work that is important and has to be done, but not something to drown yourself in. Sometimes it's also better to try to solve the root causes, like use css variables, introduce swagger or a more reliable test framework. You want the engineer who codes themselves out of the job of trivial tickets.
  - Areading314 4y ago
    fixing bugs is more important than trivial stuff like swagger, css variables, or adding new test frameworks. Function over form

WalterBright 4y ago

I love being able to fix a bug with a one line change.

DeathArrow 4y ago
I love deleting lines. The more lines I delete, the less bugs.
tcoff91 4y ago
The hardest bugs to find are often the ones that can be fixed with a one line change. If you figure out a bug quickly, then you are usually in trouble and have to refactor your codebase to resolve it or introduce an awful hack to fix it.

willio58 4y ago

I 100% object to code reviews in this way. If you have dignity as a developer you’d quit swiftly.

jxf 4y ago
My advice to someone earlier in their career would not be to quit, but to make them pay you while you look for your next job if the writing is already on the wall.
- GolfPopper 4y ago
  Yep. Phone it in while you job hunt, without making it completely obvious that's what you doing. I'd be a little surprised if most twitter devs (and anyone else) who can leave, and aren't personally invested in Twitter, are not already doing this.
  - x86x87 4y ago
    Lol. People have been leaving in large numbers ever since this circus began. The exodus will continue.
DeathArrow 4y ago
So having dignity means having a financial loss and be job hunting for some time? Why should someone get punished for having dignity?
- freejazz 4y ago
  > Why should someone get punished for having dignity? We've got a student of history

eterevsky 4y ago

I don't think the code review involves counting the lines. A reviewer can distinguish hundreds of lines of boilerplate from a non-trivial few lines change.

seadan83 4y ago
Agree, I would expect the first question after "what did you change", would be "walk me through the impact of this change"

chromakode 4y ago

"Making chalk mark on generator $1. Knowing where to make mark $9,999." https://www.smithsonianmag.com/history/charles-proteus-steinmetz-the-wizard-of-schenectady-51912022/ https://www.smithsonianmag.com/history/charles-proteus-stein...

smk_ 4y ago

I would imagine this fact is obvious to any Tesla engineers reviewing code. I would imagine they look at more factors than simply lines of code.

deleted 4y ago

[deleted]