5 ms·

I see a troubling trend with some coworkers where they seem to stretch the limits of time and space to make every line as dense as possible, usually using lodas

I see a troubling trend with some coworkers where they seem to stretch the limits of time and space to make every line as dense as possible, usually using lodash. I think it is a point of pride for them, but I think it's obvious that everyone's life would be easier if they just wrote their code out "long form" and, god willing, added some comments for various steps. Instead, I find myself having to re-write ultra-dense blobs of code in order to debug or even simply understand what's going on.

whynotminot 4y ago
I think there's a real smell with those long, dense lines of code. Tends to mean your data structures are out of control: objects with arrays that point to other objects that then also have arrays on them. My oh my. Comments being required are also another smell that the code doesn't explain itself. I know this is said so often it's a cliche, but it really is true. I think both of these things point back to the same problem: out of control data structures.
- guenthert 4y ago
  Sure, if the computer can figure out what a given fragment of code is supposed to do, so can you (a sufficiently clever programmer). The question rather is, do you spend 20s reading a comment or 15m to solve the riddle? There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes. This is one of the corners where there will never be a single answer which is right in all circumstances.
  - ethbr0 4y ago
    > There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes. So much this. If it took you everything you learned over the last week + an epiphany to come up with a bit of code, how is someone scanning through supposed to understand it? Or, in example with hilariously apropos incomplete post-hoc comments, 0x5F3759DF https://en.m.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code https://en.m.wikipedia.org/wiki/Fast_inverse_square_root#Ove...
  - BurningFrog 4y ago
    Often, breaking out a well named variable or three is the better way to make code readable.
  - ParetoOptimal 4y ago
    > There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes That problem exists because no one denies pull requests or rejects code that has outdated comments.
RajT88 4y ago
I had a professor who did that. He'd write a solution to the assignments he was giving us, and then spend another 5-8 hours on it trying to make it fit on a single overhead slide. He was a much beloved professor.
professorTuring 4y ago
It is not new, it’s been ages since some developers try to show off by bringing “cool” one liners to solve problems. Stretching operators, bringing up imaginative uses for lambda expressions or kind of abusing parts of the language to make some other teammate or reviewer, What did you make there? I believe, definitely, that they are quite intelligent people that know a lot about the language or maths, but definitely they are not usually making the smartest choice, because you should use “languages” in order for the people to understand you. So you can call those: “50 cent expressions” They help no one but their ego…
- f1shy 4y ago
  In the last times I’ve been seeing lots of “show off” with nitty gritty features of C++… lambdas, templates and inheritance in a pattern that reminds me to the characters in an Agatha Christie book, where you need a graph to keep up with it… Hope this era ends soon.
- ParetoOptimal 4y ago
  At least in Haskell, I feel like this doesn't hold true. Typically more concise code takes advantage of core language abstractions. It is actually simpler unless you are unfamilar with core language abstractions, but I'd argue that's a you problem.
f1shy 4y ago
Once I read something along the lines of “every programmer goes through that phase were we wants to show how clever he is, by writing whole programs in one line. Until he understands how stupid that is”. I do not have the source, regrettably.
- ethbr0 4y ago
  I was taking my first multi-threaded resource allocation course when I first ran into the famous Kernighan quote. > “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” It clicked and instantly disabused me of the notion that smart people write code that's any smarter than the minimum required to solve the problem at hand.
  - teo_zero 4y ago
    Kernighan wrongly assumed that to do something twice as hard, you need someone twice as clever. Most probably you need someone just as clever and twice the time. It's a brilliant quote, though.
    - deleted 4y ago
      [deleted]
    - ethbr0 4y ago
      Fair. In my practical experience, it's 50/50 2x clever vs 2x time. Mostly down to task decomposition. Some of the stuff in compiler debugging? Just 2x clever, because you have to hold it all in your head at once to solve it. Circuit debugging or data transformation debugging? You can break it down into smaller pieces, then methodically (and laboriously) worth through those pieces.
ParetoOptimal 4y ago
> I see a troubling trend with some coworkers where they seem to stretch the limits of time and space to make every line as dense as possible, usually using lodash. I think it is a point of pride for them, but I think it's obvious that everyone's life would be easier if they just wrote their code out "long form" Concision can be used for emphasis as verbosity can be used to obscure. > Instead, I find myself having to re-write ultra-dense blobs of code in order to debug or even simply understand what's going on. Is this problem because their method is inherently nee complex or is it due to lack of familiarity? Perhaps they debug that code differently then you do and it's incompatible with your previous mental model?
syntheticcdo 4y ago
Do your co-workers use lodash's chain functionality? I've found it useful to achieve kouteiheika's ideal from the current top comment, with top to bottom readability without too much mental overhead. As an example, given: const sales = [ {month: "Jan", day: 1, total: 120 }, ... ] You could determine, say, the highest sales day of a given month as follows: const highestSalesDayByMonth = _.chain(sales) .groupBy("month") .mapValues((salesForMonth) => _.maxBy(salesForMonth, "total")) .mapValues("total") .value() // highestSalesDayByMonth = { Jan: 140, Feb: 90, ... } Naturally, minimizing the complexity of the iteratee functions and carefully naming of their arguments is very important to ease debuggability.

whynotminot 4y ago

I think there's a real smell with those long, dense lines of code. Tends to mean your data structures are out of control: objects with arrays that point to other objects that then also have arrays on them. My oh my. Comments being required are also another smell that the code doesn't explain itself. I know this is said so often it's a cliche, but it really is true. I think both of these things point back to the same problem: out of control data structures.

guenthert 4y ago
Sure, if the computer can figure out what a given fragment of code is supposed to do, so can you (a sufficiently clever programmer). The question rather is, do you spend 20s reading a comment or 15m to solve the riddle? There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes. This is one of the corners where there will never be a single answer which is right in all circumstances.
- ethbr0 4y ago
  > There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes. So much this. If it took you everything you learned over the last week + an epiphany to come up with a bit of code, how is someone scanning through supposed to understand it? Or, in example with hilariously apropos incomplete post-hoc comments, 0x5F3759DF https://en.m.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code https://en.m.wikipedia.org/wiki/Fast_inverse_square_root#Ove...
- BurningFrog 4y ago
  Often, breaking out a well named variable or three is the better way to make code readable.
- ParetoOptimal 4y ago
  > There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes That problem exists because no one denies pull requests or rejects code that has outdated comments.

RajT88 4y ago

I had a professor who did that. He'd write a solution to the assignments he was giving us, and then spend another 5-8 hours on it trying to make it fit on a single overhead slide. He was a much beloved professor.

professorTuring 4y ago

It is not new, it’s been ages since some developers try to show off by bringing “cool” one liners to solve problems. Stretching operators, bringing up imaginative uses for lambda expressions or kind of abusing parts of the language to make some other teammate or reviewer, What did you make there? I believe, definitely, that they are quite intelligent people that know a lot about the language or maths, but definitely they are not usually making the smartest choice, because you should use “languages” in order for the people to understand you. So you can call those: “50 cent expressions” They help no one but their ego…

f1shy 4y ago
In the last times I’ve been seeing lots of “show off” with nitty gritty features of C++… lambdas, templates and inheritance in a pattern that reminds me to the characters in an Agatha Christie book, where you need a graph to keep up with it… Hope this era ends soon.
ParetoOptimal 4y ago
At least in Haskell, I feel like this doesn't hold true. Typically more concise code takes advantage of core language abstractions. It is actually simpler unless you are unfamilar with core language abstractions, but I'd argue that's a you problem.

f1shy 4y ago

Once I read something along the lines of “every programmer goes through that phase were we wants to show how clever he is, by writing whole programs in one line. Until he understands how stupid that is”. I do not have the source, regrettably.

ethbr0 4y ago
I was taking my first multi-threaded resource allocation course when I first ran into the famous Kernighan quote. > “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” It clicked and instantly disabused me of the notion that smart people write code that's any smarter than the minimum required to solve the problem at hand.
- teo_zero 4y ago
  Kernighan wrongly assumed that to do something twice as hard, you need someone twice as clever. Most probably you need someone just as clever and twice the time. It's a brilliant quote, though.
  - deleted 4y ago
    [deleted]
  - ethbr0 4y ago
    Fair. In my practical experience, it's 50/50 2x clever vs 2x time. Mostly down to task decomposition. Some of the stuff in compiler debugging? Just 2x clever, because you have to hold it all in your head at once to solve it. Circuit debugging or data transformation debugging? You can break it down into smaller pieces, then methodically (and laboriously) worth through those pieces.

ParetoOptimal 4y ago

> I see a troubling trend with some coworkers where they seem to stretch the limits of time and space to make every line as dense as possible, usually using lodash. I think it is a point of pride for them, but I think it's obvious that everyone's life would be easier if they just wrote their code out "long form" Concision can be used for emphasis as verbosity can be used to obscure. > Instead, I find myself having to re-write ultra-dense blobs of code in order to debug or even simply understand what's going on. Is this problem because their method is inherently nee complex or is it due to lack of familiarity? Perhaps they debug that code differently then you do and it's incompatible with your previous mental model?

syntheticcdo 4y ago

Do your co-workers use lodash's chain functionality? I've found it useful to achieve kouteiheika's ideal from the current top comment, with top to bottom readability without too much mental overhead. As an example, given: const sales = [ {month: "Jan", day: 1, total: 120 }, ... ] You could determine, say, the highest sales day of a given month as follows: const highestSalesDayByMonth = _.chain(sales) .groupBy("month") .mapValues((salesForMonth) => _.maxBy(salesForMonth, "total")) .mapValues("total") .value() // highestSalesDayByMonth = { Jan: 140, Feb: 90, ... } Naturally, minimizing the complexity of the iteratee functions and carefully naming of their arguments is very important to ease debuggability.