7 ms·

I can't directly speak to any particular work you're describing, but "smart" people don't usually add significant complexity and aren't hard to work with. Thei

I can't directly speak to any particular work you're describing, but "smart" people don't usually add significant complexity and aren't hard to work with. Their solutions tend to be obvious in hindsight and simple. They work within the constraints they're given. They don't merely find one solution and push it through. They get satisfaction finding which fits best. If there's conflict, it's probably because they don't know how else to solve something. It's true that sometimes there's only one solution, but that's rare and implies you're hitting bedrock fundamental stuff or have an over-constrained codebase that needs some refactoring. In those cases it would be apparent in other places too, not just when dealing with their code or opinions.

taneq 4y ago
All of this. Truly smart people make things easier for everyone, and usually solve problems in beautifully simple ways.
- shapefrog 4y ago
  That often goes unnoticed and can, to an outside observer, look like a "lazy" worker.
- ilyt 4y ago
  I think that's overloading the meaning of the word.
muzani 4y ago
I think I understand what OP means. I work with some smart people who use code like val x: Pair<String, Pair<String, String>> instead of say data class Status(key: String, value: String) data class Item(name: String, status: Status) val x: Item To the smart ones who can keep everything in their head, the first block of code is trivial and obvious and they don't even notice that it's hard for others to read and easy to make mistakes in.
- zepolen 4y ago
  The actual smart ones would realize they are writing code for others rather than themselves and go with the latter.
  - delecti 4y ago
    That's a very useful lesson. Also recognizing that you won't remember the code the next time you see it. It only took me a couple instances of "what moron wrote this? ...oh, it was me" before I started including myself in the "dumb future people" I'm writing my code for.
- killingtime74 4y ago
  Your way is better because when compiled it is the same bytecode and it’s clearer
- nohuck13 4y ago
  It could also be inexperience. If your experience is limited to academic projects, grinding leetcode, even competitive programming, you've done things where first one is nearly always optimal. Once you are on a team optimizing for continued feature delivery over time, the cognitive load of picking up and understanding old code full of raw maps and strings starts to justify the overhead of a bit more semantic scaffolding in places. IMO the necessary judgment has to be learned even by smart, academically talented people.
  - franciscop 4y ago
    I've rarely worked in a team where the extra scaffolding was ever worth it. In fact chasing the scaffolding scattered through varied files through the filesystem was a lot trickier usually than fixing the actual bug I was trying to fix.
    - nohuck13 4y ago
      Design pattern spaghetti is absolutely a thing. I feel like self-contained, self-describing, potentially self-validating data types like in the parent comment would tend to be complexity-reducing as long as they don't mix in control flow or deep deep inheritance hierarchies, though.
lawn 4y ago
Yeah, I see the people OP describes as clever but not wise (and thus not smart). And I've been one of them, and I now try to avoid complexity if possible and try to make peace with the fact that the smart solution is most often not the clever one.
- bayesian_horse 4y ago
  The word you're looking for is "mature".
- icepat 4y ago
  I think the main problem is the reverse Dunning Kruger effect. It can be very hard to tell what's not obvious to another person when the entire thing is self-explanatory to you. The two most intelligent people I know write code that works incredibly well, but you can tell it was coded out in one shot based on an idea they had. Makes it difficult to read, but to them it "just makes sense". A really good friend of mine is like this. When I read over his code, it's highly compact, and makes use of language features that are pretty obscure. The stuff he builds out addresses problem I would never have thought of. But the catch is I can't follow, or understand half his code. Sometimes though, there's an advantage here. Someone like that can get all the ideas out "on paper" (so to speak), then pass it off to someone who can make it legible for everyone else. There's a lot of value in someone like this, but you need to pair them up with the software equivalent of an editor. You'd be surprised, some people enjoy doing that!
  - tjrDL6MjB2Zwwa 4y ago
    To quote Dennis Ritchie. "I can't read German, does that make it unreadable?". Or to put it another way, we don't criticize James Clavelle's novel Shogun because it's difficult for a 10 year old to understand.
ilyt 4y ago
> I can't directly speak to any particular work you're describing, but "smart" people don't usually add significant complexity and aren't hard to work with. I feel that's really unrelated to how "smart" person is. It's more due to experience when you start to appreciate the simplest approaches to solve the problem. Many people chase some new and cool features and want to use them just because it is more interesting that clapping out boring code day in day out and that's where you get those overly clever blocks of code. I've seen every level of competence fall into it. Hell, I suspect like 3/4 of k8s and related deployment are exactly that, devs bored and wanting to play with new toy.
- rubyfan 4y ago
  To build on your comment…I think picking simple or anti-complexity is a values call perhaps enabled by emotional intelligence and being secure in who you are. I have met many people whose identity is wrapped up in being smart. When faced with choosing a clever solution or an understandable solution they will choose the former. This is where preserving their identity outweighs empathy for you or even for themselves. Some people also like to be the hero. If they are the only ones who get the solution then they are more likely to be the hero to fix it in some future moment of need.
  - makapuf 4y ago
    A way to make it more interesting to those is to describe simplicity as something hard to achieve and that needs to be smart.
  - smaudet 4y ago
    There is a balance too between simply being older and being young and feisty, though. This smacks a bit of old arguments to 'just use assembly' or the like. It is true there is an overproliferation of reinvention of syntax, but I have seen often older developers claim something is 'easier to read' not because it is actually so but because they are used to a certain cognitive load. A good example is an aversion or misunderstanding of properties - these were first popularized by flash as3, informally entrenched against by get/set in Java, and finally enjoyed better syntactical support and syntaxes in C#. I have experienced a degree of pushback that properties are 'complex' or unreadable, when in fact the syntax is evolving to create something simpler and more cognitively manageable. What is easily understood over time also changes, as newer frameworks become popular or more widely taught and understood, so the esoteric becomes widespread and the widespread becomes esoteric. A good way to manage this tension for experienced yet aging developers and young yet inexperienced I think is two fold - make regular yet conservative pushes for 'modernization', so that there is room for the new concepts to enter without wholesale refactoring being necessary, while still allowing for the codebase to be understood by both new and old. The other is to require new features, styles, to be well documented, both externally and with in source commenting. This pushes even the new developers to consider the cognitive ramifications of the code they are creating, while also making the code clear to those less gifted or less syntactically experienced.
thraxil 4y ago
I've worked in academia doing a lot of simulation/modeling work with scientists that are experts in their field. Brilliant people but my experience is that scientists often generate the worst code you've ever seen. They are very smart, able to reason about extremely complex things, but they have often only learned just enough programming to solve the immediate problem they're working on and rarely need to maintain code past executing it once or twice to generate the data for their paper. So functions that are thousands of lines long with tons of mutable global state, loops nested halfway across the screen, no error handling, hacks like `eval`-ing strings because no one ever told them what a hashtable was, etc. The main difference from what OP has described is that despite those problems, the smart scientists are usually not hard to work with or stubborn about wanting to add unecessary complexity; learning "proper" software development was just never a focus for them.
- jrumbut 4y ago
  The other thing I've run into in a similar context is perfectly performed manual work ("you didn't know about the merge function, so you manually typed the 15,000 rows of data into Excel?" And invariably, after coding it up, no errors found) or reimplementing things you could easily find in open source ("you didn't know about the merge function, so you found a textbook on relational algebra and implemented your own RDBMS in VB macros?" Again, a bug free toy database). Some people are just smarter/faster/better than the rest of us, but they're no better at reading programming language documentation.
- hooverd 4y ago
  Honestly, the NIH should give grants for software engineers to come in and clean things up.
pwillia7 4y ago
I agree -- If they're really that great and smart, surely better scoped technical goals will wrangle them without pushing them off
intelVISA 4y ago
Yup, working smart is doing 5 days work in 1 and making complex things simple.

taneq 4y ago

All of this. Truly smart people make things easier for everyone, and usually solve problems in beautifully simple ways.

shapefrog 4y ago
That often goes unnoticed and can, to an outside observer, look like a "lazy" worker.
ilyt 4y ago
I think that's overloading the meaning of the word.

muzani 4y ago

I think I understand what OP means. I work with some smart people who use code like val x: Pair<String, Pair<String, String>> instead of say data class Status(key: String, value: String) data class Item(name: String, status: Status) val x: Item To the smart ones who can keep everything in their head, the first block of code is trivial and obvious and they don't even notice that it's hard for others to read and easy to make mistakes in.

zepolen 4y ago
The actual smart ones would realize they are writing code for others rather than themselves and go with the latter.
- delecti 4y ago
  That's a very useful lesson. Also recognizing that you won't remember the code the next time you see it. It only took me a couple instances of "what moron wrote this? ...oh, it was me" before I started including myself in the "dumb future people" I'm writing my code for.
killingtime74 4y ago
Your way is better because when compiled it is the same bytecode and it’s clearer
nohuck13 4y ago
It could also be inexperience. If your experience is limited to academic projects, grinding leetcode, even competitive programming, you've done things where first one is nearly always optimal. Once you are on a team optimizing for continued feature delivery over time, the cognitive load of picking up and understanding old code full of raw maps and strings starts to justify the overhead of a bit more semantic scaffolding in places. IMO the necessary judgment has to be learned even by smart, academically talented people.
- franciscop 4y ago
  I've rarely worked in a team where the extra scaffolding was ever worth it. In fact chasing the scaffolding scattered through varied files through the filesystem was a lot trickier usually than fixing the actual bug I was trying to fix.
  - nohuck13 4y ago
    Design pattern spaghetti is absolutely a thing. I feel like self-contained, self-describing, potentially self-validating data types like in the parent comment would tend to be complexity-reducing as long as they don't mix in control flow or deep deep inheritance hierarchies, though.

lawn 4y ago

Yeah, I see the people OP describes as clever but not wise (and thus not smart). And I've been one of them, and I now try to avoid complexity if possible and try to make peace with the fact that the smart solution is most often not the clever one.

bayesian_horse 4y ago
The word you're looking for is "mature".
icepat 4y ago
I think the main problem is the reverse Dunning Kruger effect. It can be very hard to tell what's not obvious to another person when the entire thing is self-explanatory to you. The two most intelligent people I know write code that works incredibly well, but you can tell it was coded out in one shot based on an idea they had. Makes it difficult to read, but to them it "just makes sense". A really good friend of mine is like this. When I read over his code, it's highly compact, and makes use of language features that are pretty obscure. The stuff he builds out addresses problem I would never have thought of. But the catch is I can't follow, or understand half his code. Sometimes though, there's an advantage here. Someone like that can get all the ideas out "on paper" (so to speak), then pass it off to someone who can make it legible for everyone else. There's a lot of value in someone like this, but you need to pair them up with the software equivalent of an editor. You'd be surprised, some people enjoy doing that!
- tjrDL6MjB2Zwwa 4y ago
  To quote Dennis Ritchie. "I can't read German, does that make it unreadable?". Or to put it another way, we don't criticize James Clavelle's novel Shogun because it's difficult for a 10 year old to understand.

ilyt 4y ago

> I can't directly speak to any particular work you're describing, but "smart" people don't usually add significant complexity and aren't hard to work with. I feel that's really unrelated to how "smart" person is. It's more due to experience when you start to appreciate the simplest approaches to solve the problem. Many people chase some new and cool features and want to use them just because it is more interesting that clapping out boring code day in day out and that's where you get those overly clever blocks of code. I've seen every level of competence fall into it. Hell, I suspect like 3/4 of k8s and related deployment are exactly that, devs bored and wanting to play with new toy.

rubyfan 4y ago
To build on your comment…I think picking simple or anti-complexity is a values call perhaps enabled by emotional intelligence and being secure in who you are. I have met many people whose identity is wrapped up in being smart. When faced with choosing a clever solution or an understandable solution they will choose the former. This is where preserving their identity outweighs empathy for you or even for themselves. Some people also like to be the hero. If they are the only ones who get the solution then they are more likely to be the hero to fix it in some future moment of need.
- makapuf 4y ago
  A way to make it more interesting to those is to describe simplicity as something hard to achieve and that needs to be smart.
- smaudet 4y ago
  There is a balance too between simply being older and being young and feisty, though. This smacks a bit of old arguments to 'just use assembly' or the like. It is true there is an overproliferation of reinvention of syntax, but I have seen often older developers claim something is 'easier to read' not because it is actually so but because they are used to a certain cognitive load. A good example is an aversion or misunderstanding of properties - these were first popularized by flash as3, informally entrenched against by get/set in Java, and finally enjoyed better syntactical support and syntaxes in C#. I have experienced a degree of pushback that properties are 'complex' or unreadable, when in fact the syntax is evolving to create something simpler and more cognitively manageable. What is easily understood over time also changes, as newer frameworks become popular or more widely taught and understood, so the esoteric becomes widespread and the widespread becomes esoteric. A good way to manage this tension for experienced yet aging developers and young yet inexperienced I think is two fold - make regular yet conservative pushes for 'modernization', so that there is room for the new concepts to enter without wholesale refactoring being necessary, while still allowing for the codebase to be understood by both new and old. The other is to require new features, styles, to be well documented, both externally and with in source commenting. This pushes even the new developers to consider the cognitive ramifications of the code they are creating, while also making the code clear to those less gifted or less syntactically experienced.

thraxil 4y ago

I've worked in academia doing a lot of simulation/modeling work with scientists that are experts in their field. Brilliant people but my experience is that scientists often generate the worst code you've ever seen. They are very smart, able to reason about extremely complex things, but they have often only learned just enough programming to solve the immediate problem they're working on and rarely need to maintain code past executing it once or twice to generate the data for their paper. So functions that are thousands of lines long with tons of mutable global state, loops nested halfway across the screen, no error handling, hacks like `eval`-ing strings because no one ever told them what a hashtable was, etc. The main difference from what OP has described is that despite those problems, the smart scientists are usually not hard to work with or stubborn about wanting to add unecessary complexity; learning "proper" software development was just never a focus for them.

jrumbut 4y ago
The other thing I've run into in a similar context is perfectly performed manual work ("you didn't know about the merge function, so you manually typed the 15,000 rows of data into Excel?" And invariably, after coding it up, no errors found) or reimplementing things you could easily find in open source ("you didn't know about the merge function, so you found a textbook on relational algebra and implemented your own RDBMS in VB macros?" Again, a bug free toy database). Some people are just smarter/faster/better than the rest of us, but they're no better at reading programming language documentation.
hooverd 4y ago
Honestly, the NIH should give grants for software engineers to come in and clean things up.

pwillia7 4y ago

I agree -- If they're really that great and smart, surely better scoped technical goals will wrangle them without pushing them off

intelVISA 4y ago

Yup, working smart is doing 5 days work in 1 and making complex things simple.