4 ms·

> This advice boils down to "write good code." Unfortunately, practical advice that goes beyond that is really hard. I don't think that's true. I think a bette

> This advice boils down to "write good code." Unfortunately, practical advice that goes beyond that is really hard. I don't think that's true. I think a better way to phrase it is "avoid being clever if you don't need to be." Sure, you could write that algorithm as three nested list comprehensions, but does that accomplish anything other than showing off? Do you really need that metaprogramming or would a simple function suffice? The worst code I've ever had to deal with was never written by juniors, it was written by guys that knew fancy template metaprogramming in C++ and would create a nightmare for everyone else to deal with because they wanted to show how smart they were.

bcrosby95 3y ago
My friends call this the complexity hump. Pretty much everyone goes through this phase. The faster you get out of it the better. Some stay there their whole career.
- klabb3 3y ago
  > Some stay there their whole career. A massive cohort of programmers, some at very high positions that are highly analytically minded, do not understand this. It’s not for a lack of intelligence, but curiosity and empathy (as in the dictionary definition - the theory of mind stuff). My current best way I try to explain this is: go ahead, assume you’re 10% or even 200% smarter than others - a true 10x engineer. It doesn’t matter, because complexity scales not linearly but exponentially. The difference between big brain and small brain is minuscule in face of the omnipresent beast of complexity. It’s like surviving a terminal desease - an athlete might live longer but you’re still gonna die. And complexity creeps in simply as a byproduct of doing anything, so ignoring it will result in more, just like more code leads to more bugs. at least grug can see T-Rex
  - xyzzy_plugh 3y ago
    I think a big part of the problem is the inherited collective ego of software being birthed by computer science. If you go look at early software, early Unix, whatever, there is such a tremendous volume of really clever things going on. Little DSLs, weird experiments that bled into POSIX. All the effort devoted to grammars and compilers and making Hard Problems look Easy. I sometimes get frustrated that my colleagues don't know how to read an awk script, or that they think it's just a fact of life that they have to delete their git repository and perform a fresh clone because that's just the way npm is sometimes. Am I asking for too much? But then I remember that we have built all of this on impossibly tall ivory towers of complexity. It's almost unfathomable. Almost every project is someone's vice in this vein form of worship we call software development. We tell ourselves that we've moved past this phase, we've seen what complexity really is. But can we actually? Ever? Are we just fooling ourselves? It always seemed to me that it's ideal to use sophisticated tools to build mundane and interesting solutions. But every solution is just a tool for someone else. So much of what I love about what we do is hopelessly couples to that very complexity I despise. How can we reconcile this? Out of sight, out of mind, I suppose. I think the real problem is that we consider this all one big profession when in reality it's as varied as the crafts: electricians, plumbers, metalworkers, laborers, carpenters, mechanics, engineers, architects, painters, roofers, landscapers... We just do it all.
    - klabb3 3y ago
      > But can we actually? Ever? Are we just fooling ourselves? I don’t have any hopes of the deepest theoretical complexity problems will be solved. However, let’s not be too defeatist. Look back 10-20-30 years. The things that survive in the long run (longer than a ~5y hype-cycle) are almost always an improvement compared to the past. Some genies can’t be put back in the bottle - good ideas, models and abstractions fit that bill, in my view. I’m hopeful. > Out of sight, out of mind, I suppose. Yes but this isn’t always bad. Things like schedulers, compilers, query planners should be out of mind. Or at least it’s the best way we can compartmentalize complexity today. It’s a last resort, so you shouldn’t pick immature and highly complex deps at the same time. Fortunately, we have mature tech that does a lot of heavy lifting, even if magical.
  - kookamamie 3y ago
    If you only have grugs, you will never solve the difficult problems, though. There's no binary advice to be given around complexity - whether to avoid it or to embrace it, I think.
    - incrudible 3y ago
      Most programming is not really a difficult problem, in fact it is rather boring. That is why 200IQ programmers are constantly making it more complex than necessary. They need a challenge. Plus, it gives them authority.
    - klabb3 3y ago
      In a way yes. If we only settled for mature tech ever, we wouldn’t get anywhere. However, even for new ideas and abstractions complexity should always be avoided. All else equal, less complexity is better.
  - aitchnyu 3y ago
    Yup, moving from 40 hour weeks to 168 hour weeks (if the body supports) or a 4x hiring spree (if they integrate into the team) seems like nothing for some complicated crap I've seen.
lmm 3y ago
> Sure, you could write that algorithm as three nested list comprehensions, but does that accomplish anything other than showing off? Ask different programmers this and you'll get different answers. One group will say that the list comprehensions reduces ceremony and makes the essential business logic clear, and writing out a loop longhand would serve no purpose other than showing off your knowledge of implementation trivia. Another group would say that writing the code without using list comprehensions makes it simpler, and the other group is just showing off their knowledge of language features. "Make it simpler" advice is rarely actionable and usually just makes the debates more contentious. https://m50d.github.io/2018/12/11/people-who-disagree https://m50d.github.io/2018/12/11/people-who-disagree
- yen223 3y ago
  One of the annoying things about "code simplicity" is that it is a subjective trait. Whether a piece of code is simple to understand depends very heavily on what the reader is used to, and that's not something that the writer of the code has much control over.
  - zakirullin 3y ago
    "Code simplicity" is indeed too abstract. "Cognitive load", however, is more tangible thing to grasp. https://github.com/zakirullin/cognitive-load https://github.com/zakirullin/cognitive-load
    - lmm 3y ago
      That has pretty much the same problem. Assembly programs have low "cognitive load" by that definition, but few would say that assembly programs are simpler.
      - zakirullin 3y ago
        I wouldn't say so. When you're on assembly programs, you hold things like "register values" in your head as well as other low-level things. It's not only about abstractions and language features.

bcrosby95 3y ago

My friends call this the complexity hump. Pretty much everyone goes through this phase. The faster you get out of it the better. Some stay there their whole career.

klabb3 3y ago
> Some stay there their whole career. A massive cohort of programmers, some at very high positions that are highly analytically minded, do not understand this. It’s not for a lack of intelligence, but curiosity and empathy (as in the dictionary definition - the theory of mind stuff). My current best way I try to explain this is: go ahead, assume you’re 10% or even 200% smarter than others - a true 10x engineer. It doesn’t matter, because complexity scales not linearly but exponentially. The difference between big brain and small brain is minuscule in face of the omnipresent beast of complexity. It’s like surviving a terminal desease - an athlete might live longer but you’re still gonna die. And complexity creeps in simply as a byproduct of doing anything, so ignoring it will result in more, just like more code leads to more bugs. at least grug can see T-Rex
- xyzzy_plugh 3y ago
  I think a big part of the problem is the inherited collective ego of software being birthed by computer science. If you go look at early software, early Unix, whatever, there is such a tremendous volume of really clever things going on. Little DSLs, weird experiments that bled into POSIX. All the effort devoted to grammars and compilers and making Hard Problems look Easy. I sometimes get frustrated that my colleagues don't know how to read an awk script, or that they think it's just a fact of life that they have to delete their git repository and perform a fresh clone because that's just the way npm is sometimes. Am I asking for too much? But then I remember that we have built all of this on impossibly tall ivory towers of complexity. It's almost unfathomable. Almost every project is someone's vice in this vein form of worship we call software development. We tell ourselves that we've moved past this phase, we've seen what complexity really is. But can we actually? Ever? Are we just fooling ourselves? It always seemed to me that it's ideal to use sophisticated tools to build mundane and interesting solutions. But every solution is just a tool for someone else. So much of what I love about what we do is hopelessly couples to that very complexity I despise. How can we reconcile this? Out of sight, out of mind, I suppose. I think the real problem is that we consider this all one big profession when in reality it's as varied as the crafts: electricians, plumbers, metalworkers, laborers, carpenters, mechanics, engineers, architects, painters, roofers, landscapers... We just do it all.
  - klabb3 3y ago
    > But can we actually? Ever? Are we just fooling ourselves? I don’t have any hopes of the deepest theoretical complexity problems will be solved. However, let’s not be too defeatist. Look back 10-20-30 years. The things that survive in the long run (longer than a ~5y hype-cycle) are almost always an improvement compared to the past. Some genies can’t be put back in the bottle - good ideas, models and abstractions fit that bill, in my view. I’m hopeful. > Out of sight, out of mind, I suppose. Yes but this isn’t always bad. Things like schedulers, compilers, query planners should be out of mind. Or at least it’s the best way we can compartmentalize complexity today. It’s a last resort, so you shouldn’t pick immature and highly complex deps at the same time. Fortunately, we have mature tech that does a lot of heavy lifting, even if magical.
- kookamamie 3y ago
  If you only have grugs, you will never solve the difficult problems, though. There's no binary advice to be given around complexity - whether to avoid it or to embrace it, I think.
  - incrudible 3y ago
    Most programming is not really a difficult problem, in fact it is rather boring. That is why 200IQ programmers are constantly making it more complex than necessary. They need a challenge. Plus, it gives them authority.
  - klabb3 3y ago
    In a way yes. If we only settled for mature tech ever, we wouldn’t get anywhere. However, even for new ideas and abstractions complexity should always be avoided. All else equal, less complexity is better.
- aitchnyu 3y ago
  Yup, moving from 40 hour weeks to 168 hour weeks (if the body supports) or a 4x hiring spree (if they integrate into the team) seems like nothing for some complicated crap I've seen.

lmm 3y ago

> Sure, you could write that algorithm as three nested list comprehensions, but does that accomplish anything other than showing off? Ask different programmers this and you'll get different answers. One group will say that the list comprehensions reduces ceremony and makes the essential business logic clear, and writing out a loop longhand would serve no purpose other than showing off your knowledge of implementation trivia. Another group would say that writing the code without using list comprehensions makes it simpler, and the other group is just showing off their knowledge of language features. "Make it simpler" advice is rarely actionable and usually just makes the debates more contentious. https://m50d.github.io/2018/12/11/people-who-disagree https://m50d.github.io/2018/12/11/people-who-disagree

yen223 3y ago
One of the annoying things about "code simplicity" is that it is a subjective trait. Whether a piece of code is simple to understand depends very heavily on what the reader is used to, and that's not something that the writer of the code has much control over.
- zakirullin 3y ago
  "Code simplicity" is indeed too abstract. "Cognitive load", however, is more tangible thing to grasp. https://github.com/zakirullin/cognitive-load https://github.com/zakirullin/cognitive-load
  - lmm 3y ago
    That has pretty much the same problem. Assembly programs have low "cognitive load" by that definition, but few would say that assembly programs are simpler.
    - zakirullin 3y ago
      I wouldn't say so. When you're on assembly programs, you hold things like "register values" in your head as well as other low-level things. It's not only about abstractions and language features.