HN Explorer

Tell HN: After the user, the most important thing is less code

2 points by quadcore ↗ HN
In 2019, I'm surprised most programmers I see still completely underestimate the importance of having less code. Code is their friend and more code is the fix for most problems. I'll make a claim: after the user satisfaction, less code is the most important consideration you should have as a developer. Because less code is exponentially more customer satisfaction and money. It's simply more happiness for the developers (and the user).

When you have less code, you have less code to write, you have less code to read, you have less code to understand, you have less bugs, you have a smaller team, or, for the same budget, you have more time to do new features and bug fixes, you then have more customer satisfaction, you then have more money for even more features and bug fixes. All at the same time.

The way I see it, nothing beat that.

I would even stretch a bit: it seems to me, it makes judging programming skills very easy. Take a source, can you reduce it without impacting the user? if yes then bad coder else good coder. As simple as that.

How come this is completely disregarded? For example, does triplebyte tests applicants for their ability to do less code? It's not my recollection.. How come? I would even prefer a complete beginner that I'm sure do less code, than a senior who pisses lots.

Hopefully this will lead to an interesting discussion. I'd be interested to hear specifically people who disagree, I'd also be interested in ideas to make less code more known.

2 comments

[ 5.8 ms ] story [ 8.5 ms ] thread
verdverm
Agree, we just wrote 500 LOC that reads data and a spec, interpolates, validates, and provides a nice error report. This is saving us many many thousands of LOC and hours of frustrations. We are only using it in one place, and will likely start using it in more. Probably want to OSS it first, so be on the lookout for a Show HN!
x0hm
When you have less code, you have less code to write, you have less code to read, you have less code to understand, you have less bugs, you have a smaller team, or, for the same budget, you have more time to do new features and bug fixes, you then have more customer satisfaction, you then have more money for even more features and bug fixes. All at the same time.

I think blanket statements like this are short-sighted, dangerous, and just plain wrong.

Less code doesn't automatically make anything easier to understand. When my JavaScript is optimized, for instance, it's certainly less code than I wrote. But it's absolutely not understandable.

Less code doesn't automatically reduce your bug count. I can have as many bugs in 40 lines of code as I can in 400.

Less code doesn't give you more time to add new features or fix bugs. In fact, if your code is less understandable, you're going to have a lot of cognitive debt which will increase the amount of time it takes to understand and add new features.

Less code isn't useful. Understandable code is. Sometimes those ideas align. Sometimes, though, understandable code is more verbose.

Instead, you should write ENOUGH code to get your task done, and then refactor.