4 ms·

Developers chasing their tail writing clever programs to read spaghetti code instead of not writing speghetti code. I get it. The problem is very attractive.

Developers chasing their tail writing clever programs to read spaghetti code instead of not writing speghetti code. I get it. The problem is very attractive. I get turned on thinking about it too but I would rather programmers knew how to compose code that other humans could read instead of dreaming about using AI to read incomprehensible first drafts. Teaching other developers how to write code is not fun I guess. I'm guilty too. I pull up a PR and scroll down and find a loop with some IFs and God forbid a map or some other inline atrocity sitting in a well named method with well named variables (they sort of get it)...and there I am trying to judge intent. I give up and just go to lunch in disgust, I don't have time to teach someone how express intent, nor do I have time to guess the intent. It's obvious that the code is looping over some list and digging into an object and blah blah...but why!??? The important part. When I'm long dead maybe we will require programmers to write code that other people can understand.

NateEag 6y ago
As far as I can tell, most software is changed rarely enough that writing readable code is a net loss. At every job I've had, there were piles of code that went untouched the whole time I was there, and chunks that were undergoing constant evolution. The former always massively outweighs the latter. I'm a huge fan of readable code, and try to write it myself, but the truth seems to be that it doesn't matter as much as we wish.
- jayd16 6y ago
  >The former always massively outweighs the latter. This is not enough of an argument. You can't predict what code will be read so we try to make it all readable. I consider this to still be beneficial even if most of the code is never refactored.
  - NateEag 6y ago
    Yep, you can't know in advance what code will evolve. I see that as an argument for my position, though. It's faster to write less-readable code. Documenting all your abstractions takes time, as does making sure all your names are ideal, as does making the abstractions in the first place (and they're often the wrong ones if you do them up front). A business only has so much money to spend on a tool or product, and they want maximal bang for their buck. That comes from shipping stuff fast and seeing what sticks. Once you've seen what features are evolving and matter to users, those are the ones you start refactoring and improving, both for functionality and readability. Obviously, do what you can to make your first pass readable. Don't spend lots of time on it until you have evidence this code will be modified often, though, because on average it isn't. I kind of hate this conclusion, and I'm not very good at it, but that's where I've landed these days.
thomascgalvin 6y ago
> Developers chasing their tail writing clever programs to read spaghetti code instead of not writing speghetti code. If a codebase is in development long enough, the probability of spaghetti code approaches 1. Also, some of the spaghetti I've had to fight through wasn't my fault, just my responsibility.

NateEag 6y ago

As far as I can tell, most software is changed rarely enough that writing readable code is a net loss. At every job I've had, there were piles of code that went untouched the whole time I was there, and chunks that were undergoing constant evolution. The former always massively outweighs the latter. I'm a huge fan of readable code, and try to write it myself, but the truth seems to be that it doesn't matter as much as we wish.

jayd16 6y ago
>The former always massively outweighs the latter. This is not enough of an argument. You can't predict what code will be read so we try to make it all readable. I consider this to still be beneficial even if most of the code is never refactored.
- NateEag 6y ago
  Yep, you can't know in advance what code will evolve. I see that as an argument for my position, though. It's faster to write less-readable code. Documenting all your abstractions takes time, as does making sure all your names are ideal, as does making the abstractions in the first place (and they're often the wrong ones if you do them up front). A business only has so much money to spend on a tool or product, and they want maximal bang for their buck. That comes from shipping stuff fast and seeing what sticks. Once you've seen what features are evolving and matter to users, those are the ones you start refactoring and improving, both for functionality and readability. Obviously, do what you can to make your first pass readable. Don't spend lots of time on it until you have evidence this code will be modified often, though, because on average it isn't. I kind of hate this conclusion, and I'm not very good at it, but that's where I've landed these days.

thomascgalvin 6y ago

> Developers chasing their tail writing clever programs to read spaghetti code instead of not writing speghetti code. If a codebase is in development long enough, the probability of spaghetti code approaches 1. Also, some of the spaghetti I've had to fight through wasn't my fault, just my responsibility.