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.
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.
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.
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.
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.
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.
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.
I think those are misleading on two accounts: first, it's the tip of the iceberg. Most co-workers I've spoken to don't contribute to any such open source projects. They tend to have other priorities, starting with the proprietary or custom software they are paid to write. Yes, there are many programmers writing open source code out there. I'm willing to guess however that much more time is spent on proprietary or custom software.
Second, there's a lot of unused garbage out there. Yes, there are a massive amount of code that could be used by others, but the only code you see is the tiny fraction that is actually used by many people. Such is the way of search engines, they show you a highly skewed sample, biased towards fame. (And rightly so: famous stuff everybody use tends to be what you are interested in to begin with.)
> Each developer uses a bunch of libraries, utilities and frameworks which are either FOSS or could use a FOSS alternative.
That's the thing: everybody uses a bunch of libraries and utilities all the time. I believe much fewer people writes those utilities. Or at the very least, much less time is spent writing them.
The more popular the library or utility, the more pronounced this is. Everybody can write something 10 other programmers will end up using. Very few will be (un)lucky enough to write something that have enough users to be known across the planet.
Take me for instance. I've sought my GitHub ranking¹ which is mostly concentrated in a single project². Numbers suggest I'm in the top percentile. Not the most popular code out there, but I'm doing pretty damn fine.
[1]: http://git-awards.com/users/loupvaillant [2]: https://monocypher.org
Yet: have you even heard of those? Possibly, but I'd say probably not. The top percentile simply isn't enough.
> […] 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!
Agreed. This is all a matter of degree, after all.
> I think programmers worth their salt should strive to produce code that other programmers use.
I'm not sure I agree with that goal. And I say that as someone who dreams of having a global impact. Sure, any professional worth their salt should strive to improve to at least some decent standard of excellence. (Some professions, like classical music, tend to require excellence merely to enter the field, which we could argue is maybe going a bit too far.)
Having other programmers use your stuff is a great way to have feedback and improve up to that standard, but I don't think it's not the only way. It may currently be one of the easiest, though.
> 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.
If we're going down that path, I'd go as far as to say pretty much all code should be free to begin with. Following that thought to its conclusion though, I quickly concluded that universal free software is mostly incompatible with capitalism. I can write software in my free time, but I need a salary in the first place to even have such free time. Currently, that salary comes from a day job dedicated to proprietary software.
I mean, recall the OpenSSL debacle. That piece of software is used literally everywhere, and we had to have Heartbleed for insanely rich corporations over the world to even notice that trickling a few drops of money down this project might be a good idea.
You asked "what fraction can claim they have"; and you're saying "most" of your co-workers haven't. Fair enough, it's the same for me actually. But "Most" is just over 50%. A sizable fraction have.
> Second, there's a lot of unused garbage out there.
Yes, that's true (and also a lot of unused gems). But even if we only take code that's seen use by others, my previous argument stands. Of course, "used" can mean 10 people or a Million people.
> Take me... GitHub raking... I'm in the top percentile
Wow, I didn't even know about these rankings! Thanks!
Anyway, I looked at my rankings, but more than that - I looked at the overall number of contributors. There are supposedly [1] about 24 Million software developers in the world today. Now, There are 300K C++, 300K C, 760K Java, 600K Python and 1M Javascript contributors on GitHub, Then it's pretty safe to assume that between 5% and 10% of developers contribute merely on GitHub. Actually, yeah, over 2 M active users in 2017 [2]. And again, there are other venues for FOSS contribution, like I mentioned. So dropping the unused stuff, we're still close to 10% of developers.
> I quickly concluded that universal free software is mostly incompatible with capitalism.
If you put it that way, I agree that that's the case. But - I didn't mean to say programmers should be inspired just by the fact that software can be free; I also mean that they should strive to write their software as though it were about to be released as FOSS.
[1] - https://www.daxx.com/blog/development-trends/number-software...
[2] - https://www.infoworld.com/article/3253948/who-really-contrib...
I don't think many coders can claim that much of their code from decades ago is still alive. And rightly so! The areas where code is used for that long (e.g. core banking systems) are not necessarily the most pleasant to work with.
- 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.