Hacker News Reader

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.

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.

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.

> 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.

> 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.

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.

> - 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.

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.

I think implementing new features isn't the same as maintence. Maintennce is to make something that isn't working work.

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?

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.

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.

> 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.

> 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.

> 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.

> Just look at the code of GitHub, BitBucket, Sourceforge etc

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.

> Most co-workers I've spoken to don't contribute to any such open source projects.

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...

> 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.

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.