8 ms·

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I c

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care about the end product. - Developers (less experienced?) obsess about this stuff. It is so expensive. Layers of coding management to deal with it all. - If your code requires constant maintenance you are doing it wrong. - Obeying the above rules means you can leave old software behind and generate new software if you want. I am about to celebrate 10 years of my first software (an app) I wrote for myself. It is still in prod. It is fine, been earning $$ for years. I don't touch it unless I need to support new devices or support API updates. On the flip side, there isn't much code I wrote in my previous professional career that is still live - the reason is vendors only make a profit because they need to generate cashflow constantly, and they do it by breaking the above rules unnecessarily. Do you work for a vendor? Think about the real reason you are breaking the above rules - the reason is because the extra time is billable. You are not breaking the above rules because it is the best way to write software. You are breaking the above rules because it generates the most profit for the company you work for.

quickthrower2 7y ago
When you work with your own apps you can be as messy as you like. In a team there is some incentive to make the code readable to other developers. At the lightweight end you have coding standards and linting, then design patterns then finally big refactorings. It’s all trade offs. Bug team products can have islands of code that are like one person projects and those can be messy for example.
- dx034 7y ago
  Code with duplications isn't less readable. Quite the opposite. Fighting your way through layers of abstractions and generalizations can make it harder to understand for someone new to the code. Especially code that will rarely be touched except for bug fixes, having it as simple as possible can often be worth it. And in the end, users will also appreciate this. Any time spent refactoring is time not spent on new features or bug fixes. A user doesn't care if your code is cleaner (unless it was buggy before), they'd rather have new features or improved usability.
  - therealdrag0 7y ago
    It's gotta be case-by case, but upon shallow reflection I feel like 1 layer of abstraction is the sweet spot. I've worked on code where I have to "Go-to definition" a dozen times to figure out what is going on, and I hate it. And I have seen code where it's just a big wall of text hundreds or thousands of lines long, and I hate it.
jammygit 7y ago
I find that every 1000 lines of code I write, my productivity goes down a bit more. Without refactoring, my code just gets really coupled and it gets harder to change. Your position is that the time cost of refactoring is less than that of speed up benefits?
- dx034 7y ago
  If you duplicate and don't try to generalize wherever possible, these links won't hit you as hard. Changes to one module are much less likely to cause bad behavior in others compared to code where as much logic as possible is generalized and shared between functions.
pizzazzaro 7y ago
Always fun to find an escapee of the "Russian nail factory" of modern business management. Thank you for this simple, clear explanation.
djsumdog 7y ago
> Rewriting requires retest, introduces new bugs If you don't have automated tests, and start writing them as early as you can, you're not going to have a good time. I hate working at shops or on jobs where there is zero unit testing. You have to have tests to safely refactor things. If you miss something, you add a test. If you get a false failure; figure out what was wrong with the test. Retesting should be as simple as running the test scripts. If it's not automated, it's not tested correctly.
- galangalalgol 7y ago
  I'd rather have automated integration or system test and no unit test than the other way around. I find unit tests uncover the fewest problems of the three.
einpoklum 7y ago
> There isn't much code I wrote in my previous professional career that is still live That means your impact on the world has been very limited. You haven't contributed to the basis of what other coders used. Not that this is illegitimate - but I believe we should strive further. > the reason is vendors only make a profit because they need to generate cashflow constantly, and they do it by breaking the above rules unnecessarily. 1. "vendors" don't control all code. In fact, the most important bodies of code we all use were released for general use rather than sold commercially: Free Software libraries, drivers, kernels and applications. 2. Not all commercial companies want you to write this kind of throw-away code.
- loup-vaillant 7y ago
  > You haven't contributed to the basis of what other coders used. What fraction of us can claim they have, really? Most developers work at the application layer, the last one. The more foundational your stuff is, the less of it there is, because it is reused everywhere. For similar reasons, very few people work on massively popular software. Most work on software that have only a couple users, or even just one (typically one corporate user). Very few people are famous, because fame is fundamentally scarce. Implying that every programmer worth their salt should have produced code other programmers use is just not realistic.
  - einpoklum 7y ago
    > What fraction of us can claim they have, really? I think it's larger than you imagine. Just look at the code of GitHub, BitBucket, Sourceforge etc. Not to mention self-hosted commercially-developed FOSS. > Most developers work at the application layer, the last one. Well, that doesn't mean they have to work _only_ on that. Each developer uses a bunch of libraries, utilities and frameworks which are either FOSS or could use a FOSS alternative. > For similar reasons, very few people work on massively popular software. Well, yes, this is true, but you can work on somewhat-popular or even niche software which is still used by hundreds of thousands, or just thousands, of people. That's still very significant! > Implying that every programmer worth their salt should have produced code other programmers use is just not realistic. Well, drop the "have". I think programmers worth their salt should strive to produce code that other programmers use. Morever - I believe that it's the visible code, and the free code, is what we should use as the model and the target of advice and improvement.
_tkzm 7y ago
100% agree. the difference comes from the fact that you are either a programmer or a businessman. a programmer strives for perfection, a businessman for functionality. i am trying to transition from the former to the latter but it is really hard to "get it" and "let go" of some things.
lmm 7y ago
> - If your code requires constant maintenance you are doing it wrong. Disagree. Your code should reflect the business you're in, and changes to the business are what creates opportunity and let you turn your skills into profit. Clean code is absolutely a means to an end, and if you've got a codebase that's just sitting there fulfilling some static business purpose then yes, it makes sense to leave it ugly. (Similarly with code that you know is being end-of-lifed soon - if there is not going to be a need to make changes to the code in the future then it's fine to load it up with technical debt until it sinks). But that's the exception rather than the rule.
- humanrebar 7y ago
  Even for static business purposes, the target environment changes over time. The OS gets upgraded, security bugs are discovered, dependencies become end-of-life'd, language runtimes are replaced, etc.
- jhoutromundo 7y ago
  I think implementing new features isn't the same as maintence. Maintennce is to make something that isn't working work.
drdaeman 7y ago
> Users don't care about clean code. They only care about the end product. I'd disagree. Both code and compiled product are products, with different users. Your code's users care about the code. Your product's users care about the product. The "whatever works" approach works for a solo developer of non-free software products, where there are no other users of the code. Or for one-off scripts that aren't meant to be used as code after they serve their purpose. Whenever there are other people who get to work (in any sense) on your code, things become more complicated. Which doesn't mean code must be somewhat "clean" to some standards. IMHO, the only thing that matters is that every user of the code can understand its logic and feel good (or, at least, doesn't feel bad) working on it.

quickthrower2 7y ago

When you work with your own apps you can be as messy as you like. In a team there is some incentive to make the code readable to other developers. At the lightweight end you have coding standards and linting, then design patterns then finally big refactorings. It’s all trade offs. Bug team products can have islands of code that are like one person projects and those can be messy for example.

dx034 7y ago
Code with duplications isn't less readable. Quite the opposite. Fighting your way through layers of abstractions and generalizations can make it harder to understand for someone new to the code. Especially code that will rarely be touched except for bug fixes, having it as simple as possible can often be worth it. And in the end, users will also appreciate this. Any time spent refactoring is time not spent on new features or bug fixes. A user doesn't care if your code is cleaner (unless it was buggy before), they'd rather have new features or improved usability.
- therealdrag0 7y ago
  It's gotta be case-by case, but upon shallow reflection I feel like 1 layer of abstraction is the sweet spot. I've worked on code where I have to "Go-to definition" a dozen times to figure out what is going on, and I hate it. And I have seen code where it's just a big wall of text hundreds or thousands of lines long, and I hate it.

jammygit 7y ago

I find that every 1000 lines of code I write, my productivity goes down a bit more. Without refactoring, my code just gets really coupled and it gets harder to change. Your position is that the time cost of refactoring is less than that of speed up benefits?

dx034 7y ago
If you duplicate and don't try to generalize wherever possible, these links won't hit you as hard. Changes to one module are much less likely to cause bad behavior in others compared to code where as much logic as possible is generalized and shared between functions.

pizzazzaro 7y ago

Always fun to find an escapee of the "Russian nail factory" of modern business management. Thank you for this simple, clear explanation.

djsumdog 7y ago

> Rewriting requires retest, introduces new bugs If you don't have automated tests, and start writing them as early as you can, you're not going to have a good time. I hate working at shops or on jobs where there is zero unit testing. You have to have tests to safely refactor things. If you miss something, you add a test. If you get a false failure; figure out what was wrong with the test. Retesting should be as simple as running the test scripts. If it's not automated, it's not tested correctly.

galangalalgol 7y ago
I'd rather have automated integration or system test and no unit test than the other way around. I find unit tests uncover the fewest problems of the three.

einpoklum 7y ago

> There isn't much code I wrote in my previous professional career that is still live That means your impact on the world has been very limited. You haven't contributed to the basis of what other coders used. Not that this is illegitimate - but I believe we should strive further. > the reason is vendors only make a profit because they need to generate cashflow constantly, and they do it by breaking the above rules unnecessarily. 1. "vendors" don't control all code. In fact, the most important bodies of code we all use were released for general use rather than sold commercially: Free Software libraries, drivers, kernels and applications. 2. Not all commercial companies want you to write this kind of throw-away code.

loup-vaillant 7y ago
> You haven't contributed to the basis of what other coders used. What fraction of us can claim they have, really? Most developers work at the application layer, the last one. The more foundational your stuff is, the less of it there is, because it is reused everywhere. For similar reasons, very few people work on massively popular software. Most work on software that have only a couple users, or even just one (typically one corporate user). Very few people are famous, because fame is fundamentally scarce. Implying that every programmer worth their salt should have produced code other programmers use is just not realistic.
- einpoklum 7y ago
  > What fraction of us can claim they have, really? I think it's larger than you imagine. Just look at the code of GitHub, BitBucket, Sourceforge etc. Not to mention self-hosted commercially-developed FOSS. > Most developers work at the application layer, the last one. Well, that doesn't mean they have to work _only_ on that. Each developer uses a bunch of libraries, utilities and frameworks which are either FOSS or could use a FOSS alternative. > For similar reasons, very few people work on massively popular software. Well, yes, this is true, but you can work on somewhat-popular or even niche software which is still used by hundreds of thousands, or just thousands, of people. That's still very significant! > Implying that every programmer worth their salt should have produced code other programmers use is just not realistic. Well, drop the "have". I think programmers worth their salt should strive to produce code that other programmers use. Morever - I believe that it's the visible code, and the free code, is what we should use as the model and the target of advice and improvement.

_tkzm 7y ago

100% agree. the difference comes from the fact that you are either a programmer or a businessman. a programmer strives for perfection, a businessman for functionality. i am trying to transition from the former to the latter but it is really hard to "get it" and "let go" of some things.

lmm 7y ago

> - If your code requires constant maintenance you are doing it wrong. Disagree. Your code should reflect the business you're in, and changes to the business are what creates opportunity and let you turn your skills into profit. Clean code is absolutely a means to an end, and if you've got a codebase that's just sitting there fulfilling some static business purpose then yes, it makes sense to leave it ugly. (Similarly with code that you know is being end-of-lifed soon - if there is not going to be a need to make changes to the code in the future then it's fine to load it up with technical debt until it sinks). But that's the exception rather than the rule.

humanrebar 7y ago
Even for static business purposes, the target environment changes over time. The OS gets upgraded, security bugs are discovered, dependencies become end-of-life'd, language runtimes are replaced, etc.
jhoutromundo 7y ago
I think implementing new features isn't the same as maintence. Maintennce is to make something that isn't working work.

drdaeman 7y ago

> Users don't care about clean code. They only care about the end product. I'd disagree. Both code and compiled product are products, with different users. Your code's users care about the code. Your product's users care about the product. The "whatever works" approach works for a solo developer of non-free software products, where there are no other users of the code. Or for one-off scripts that aren't meant to be used as code after they serve their purpose. Whenever there are other people who get to work (in any sense) on your code, things become more complicated. Which doesn't mean code must be somewhat "clean" to some standards. IMHO, the only thing that matters is that every user of the code can understand its logic and feel good (or, at least, doesn't feel bad) working on it.