6 ms·

One of the strangest ironies of my career is that the smartest developers often write the worst code. Their perfect memories enable them to effortlessly work wi

by _lx4l 3y ago

One of the strangest ironies of my career is that the smartest developers often write the worst code. Their perfect memories enable them to effortlessly work with infinite layers of abstraction and write the most clever solutions imaginable to any problem.

bqmjjx0kac 3y ago
And that's why my shitty memory is kind of a super power. Except for the way it makes everything else difficult.
aleksiy123 3y ago
Gotta dumb yourself down to write your best code sometimes. In this vain this often posted article is fun https://grugbrain.dev/ https://grugbrain.dev/
Instantix 3y ago
Are you sure those "smartest developers" would be still smart if they have to maintain someone else abstract code? Easy to memorize layers of abstraction when it follow your own logic and you build it step by step.
- leetrout 3y ago
  Bingo. It's different when you grow up with it.
- Hermitian909 3y ago
  Still happens. I work in a codebase that is definitely on the upper end of complexity for the industry. ~18 months ago we hired a very smart developer who had one of the more rapid onboardings to our codebase I've seen, he was very productive in under a month. It turned out he was too productive and people were starting to find new layers being added to the code base. A few of the more senior folks had to come in and shut him down.
  - zx8080 3y ago
    > shut him down. Does this mean firing him?
    - Hermitian909 3y ago
      No, it means helping him understand how certain types of contributions he makes are perceived by engineering leadership and giving him access to mentorship that would help him better channel his efforts in ways that would be seen as more productive and something to be rewarded. If, over time, he continues to introduce more problems than he solves then he might be managed out but I'm hopeful that won't happen.
tester756 3y ago
how do you define smartest developers?
- intelVISA 3y ago
  ability to solve Hard Problems rather than create them
  - ahartmetz 3y ago
    ...and to explain the solution to humans with the same code that solves the problem on a computer. It rarely happens completely, but it's a good ideal.
- ngngngng 3y ago
  I mean clearly the highest IQ people I’ve ever worked with. The smartest people I’ve worked with that are developers.
  - rgbgraph 3y ago
    By outward appearance or some other metric? Not to get on a soapbox, but I would imagine someone with great pattern recognition would be able to realize this way of doing things is deranged; and ultimately helps them more than the team- On second though: perhaps they are genuinely the smartest people in the room -- prioritizing their image and importance by making others believe they're too stupid to understand what's going on. I really should go study Gang of Four -- job security demands it.
baconforce 3y ago
a lot of it is hubris as well, they just assume that others will be able to understand it because it's easy and intuitive to them, and if others cannot understand it they must not be good developers
ldjkfkdsjnv 3y ago
If they work with developers of a similar intelligence its not a problem, and even has massive returns
mjevans 3y ago
Long ago I read something like... A debugger needs to be smarter than the person who wrote the code being debugged. If someone is at their smartest when writing a section of code, they are thus unable to successfully debug problems involving that code.
- deleted 3y ago
  [deleted]
- alwaysbeconsing 3y ago
  Indeed; this is called Kernighan's Law: > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan
  - phendrenad2 3y ago
    There's a similar saying in cryptography: "Anyone can design a lock that's so complex they can't break it".
    - TeMPOraL 3y ago
      Both do seem a bit bullshit, though. I hate to go against the Wisdom of the Ancients here, but there is no point at which you're too dumb to debug your own code. With increasing code cleverness, you may lose the ability to make quick mental jumps when debugging it - but this only forces you to be methodical. With a methodical approach, you will find the bug - the thing you might be missing is not smarts, it's patience. As for cryptography: digital locks are broken by default. It takes care and smarts to design one that isn't trivially breakable. Trying to design a lock that's too clever for you to understand will almost always yield a lock that's broken just past the boundary of your understanding, so you should be able to break it once you realize it's possible and you put a little effort. As for physical locks: same as above, plus you can always break it literally, by applying enough physical force.
analog31 3y ago
Being a savant at creating and then solving a particular kind of puzzle is certainly a form of smartness. Figuring out whether it's a form that you want to have involved in your business is another form of smartness. The principal-agent problem looms large.
biorach 3y ago
Nope, those are not the smartest developers. Those are the cleverest developers. The best developers solve the hard problems without writing the worst code.
briHass 3y ago
The key is consistency across the organization. Even with a complex (perhaps even over-engineered) standard template, it's nice to be able to open an application/service you've never worked on and have a pretty good idea how to find the key bits. The worst is a huge monolith that has dozens of styles and favorite patterns sprinkled all over from years of opinionated developers leaving their mark. For anything non-trivial, it might take an hour or two just to get your bearings and enter the mindset of the original developer. Then, you have to make the decision of whether your new function is going to follow that (broken) pattern or add yet another new one.
pschuegr 3y ago
+1. One of the single best pieces of programming advice I ever received when I was young was my TL saying "I don't like this, it's too clever". I spent a brief period at a FAANG company and IMO the people there are too smart to be good developers. My coding heuristics now pretty much boil down to: 1) Less code is better code. The only code with no bugs is no code. After you get something working, remove as much code as you can. 2) Simple code is better code. Don't waste time making your code complex for the sake of being efficient until you've used it and proven that it's a bottleneck with a profiler. Otherwise, just do the simplest thing you can think of that will work. 3) Don't think too far ahead unless you specifically have been tasked with it. Otherwise, do what will work now. Refactor when necessary.
- peterashford 3y ago
  Yep. 100% on board with this. The more code and the more complexity, the harder the system is to understand, maintain and extend.
- Groxx 3y ago
  Yeah. I summarize 1+2 as "optimize for reading" personally - none of us is as dumb as we are in the past/future, explain yourself and don't be clever without an explicit need and a way to recover from it later, etc.
tacitusarc 3y ago
This is partly true, I think. But it's more a problem of focus: the interesting part to many smart developers (and developers in general) is the initial solving of a problem. Very clever developers can go much longer without refactoring, since their cognitive capacity is higher. They can get through the initial problem solve in a single go, potentially, and have a complete mess on their hands. This is only bad if they stop there, though (many do). If they then put that cleverness to use _simplifying_ the code, they can produce some of the cleanest and best models for problems that you'll see. There's often no upside to it, though, so many just skip that step. Unfortunately.

by _lx4l 3y ago

bqmjjx0kac 3y ago

And that's why my shitty memory is kind of a super power. Except for the way it makes everything else difficult.

aleksiy123 3y ago

Gotta dumb yourself down to write your best code sometimes. In this vain this often posted article is fun https://grugbrain.dev/ https://grugbrain.dev/

Instantix 3y ago

Are you sure those "smartest developers" would be still smart if they have to maintain someone else abstract code? Easy to memorize layers of abstraction when it follow your own logic and you build it step by step.

leetrout 3y ago
Bingo. It's different when you grow up with it.
Hermitian909 3y ago
Still happens. I work in a codebase that is definitely on the upper end of complexity for the industry. ~18 months ago we hired a very smart developer who had one of the more rapid onboardings to our codebase I've seen, he was very productive in under a month. It turned out he was too productive and people were starting to find new layers being added to the code base. A few of the more senior folks had to come in and shut him down.
- zx8080 3y ago
  > shut him down. Does this mean firing him?
  - Hermitian909 3y ago
    No, it means helping him understand how certain types of contributions he makes are perceived by engineering leadership and giving him access to mentorship that would help him better channel his efforts in ways that would be seen as more productive and something to be rewarded. If, over time, he continues to introduce more problems than he solves then he might be managed out but I'm hopeful that won't happen.

tester756 3y ago

how do you define smartest developers?

intelVISA 3y ago
ability to solve Hard Problems rather than create them
- ahartmetz 3y ago
  ...and to explain the solution to humans with the same code that solves the problem on a computer. It rarely happens completely, but it's a good ideal.
ngngngng 3y ago
I mean clearly the highest IQ people I’ve ever worked with. The smartest people I’ve worked with that are developers.
- rgbgraph 3y ago
  By outward appearance or some other metric? Not to get on a soapbox, but I would imagine someone with great pattern recognition would be able to realize this way of doing things is deranged; and ultimately helps them more than the team- On second though: perhaps they are genuinely the smartest people in the room -- prioritizing their image and importance by making others believe they're too stupid to understand what's going on. I really should go study Gang of Four -- job security demands it.

baconforce 3y ago

a lot of it is hubris as well, they just assume that others will be able to understand it because it's easy and intuitive to them, and if others cannot understand it they must not be good developers

ldjkfkdsjnv 3y ago

If they work with developers of a similar intelligence its not a problem, and even has massive returns

mjevans 3y ago

Long ago I read something like... A debugger needs to be smarter than the person who wrote the code being debugged. If someone is at their smartest when writing a section of code, they are thus unable to successfully debug problems involving that code.

deleted 3y ago
[deleted]
alwaysbeconsing 3y ago
Indeed; this is called Kernighan's Law: > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan
- phendrenad2 3y ago
  There's a similar saying in cryptography: "Anyone can design a lock that's so complex they can't break it".
  - TeMPOraL 3y ago
    Both do seem a bit bullshit, though. I hate to go against the Wisdom of the Ancients here, but there is no point at which you're too dumb to debug your own code. With increasing code cleverness, you may lose the ability to make quick mental jumps when debugging it - but this only forces you to be methodical. With a methodical approach, you will find the bug - the thing you might be missing is not smarts, it's patience. As for cryptography: digital locks are broken by default. It takes care and smarts to design one that isn't trivially breakable. Trying to design a lock that's too clever for you to understand will almost always yield a lock that's broken just past the boundary of your understanding, so you should be able to break it once you realize it's possible and you put a little effort. As for physical locks: same as above, plus you can always break it literally, by applying enough physical force.

analog31 3y ago

Being a savant at creating and then solving a particular kind of puzzle is certainly a form of smartness. Figuring out whether it's a form that you want to have involved in your business is another form of smartness. The principal-agent problem looms large.

biorach 3y ago

Nope, those are not the smartest developers. Those are the cleverest developers. The best developers solve the hard problems without writing the worst code.

briHass 3y ago

The key is consistency across the organization. Even with a complex (perhaps even over-engineered) standard template, it's nice to be able to open an application/service you've never worked on and have a pretty good idea how to find the key bits. The worst is a huge monolith that has dozens of styles and favorite patterns sprinkled all over from years of opinionated developers leaving their mark. For anything non-trivial, it might take an hour or two just to get your bearings and enter the mindset of the original developer. Then, you have to make the decision of whether your new function is going to follow that (broken) pattern or add yet another new one.

pschuegr 3y ago

+1. One of the single best pieces of programming advice I ever received when I was young was my TL saying "I don't like this, it's too clever". I spent a brief period at a FAANG company and IMO the people there are too smart to be good developers. My coding heuristics now pretty much boil down to: 1) Less code is better code. The only code with no bugs is no code. After you get something working, remove as much code as you can. 2) Simple code is better code. Don't waste time making your code complex for the sake of being efficient until you've used it and proven that it's a bottleneck with a profiler. Otherwise, just do the simplest thing you can think of that will work. 3) Don't think too far ahead unless you specifically have been tasked with it. Otherwise, do what will work now. Refactor when necessary.

peterashford 3y ago
Yep. 100% on board with this. The more code and the more complexity, the harder the system is to understand, maintain and extend.
Groxx 3y ago
Yeah. I summarize 1+2 as "optimize for reading" personally - none of us is as dumb as we are in the past/future, explain yourself and don't be clever without an explicit need and a way to recover from it later, etc.

tacitusarc 3y ago

This is partly true, I think. But it's more a problem of focus: the interesting part to many smart developers (and developers in general) is the initial solving of a problem. Very clever developers can go much longer without refactoring, since their cognitive capacity is higher. They can get through the initial problem solve in a single go, potentially, and have a complete mess on their hands. This is only bad if they stop there, though (many do). If they then put that cleverness to use _simplifying_ the code, they can produce some of the cleanest and best models for problems that you'll see. There's often no upside to it, though, so many just skip that step. Unfortunately.