Comment by eternityforest | Hacker News Reader

Comment by eternityforest | Hacker News Reader

Parent Full thread

I don't really feel that attraction to complete rewriting. I wonder if the people who do are very smart, and thus able to hold more state in their head, so ugly code bothers them more even if it's not actively a problem, because they are able to have background tasks in their mind to worry about it?

And at the same time, perhaps their code is less encapsulated, because they didn't optimize for abstraction, they optimized for beauty. A leaky abstraction doesn't bother them, because ALL abstractions are leaky to them, they probably have a sense of internal workings even whem using household appliances, but ugly code tucked away somewhere bothers them a lot, and they might dislike using popular large libraries even if they work great, just because they're not comfortable using what they don't understand deeply.

My evidence of this is the fact that suckless exists and people actually use it, I assume their experience of thought is very different from anything I have experienced.

Speaking personally my urge to rewrite at least partially comes from not truly understanding the problem and the solutions to it until I've written something reasonably functional. It doesn't matter how much time I put into sitting and theorizing, there's always things I didn't anticipate and assumptions that turned out to be incorrect.

This usually means that rewrites are significant improvements across the board, especially if they're done a relatively short time after the original is finished since it's all still fresh in my head.

This may be a weakness of sorts on my part though, I lack formal engineering training which might be why purely mental modeling (no code) doesn't work all that well for me.

Yeah, I find that the desire to rewrite often comes from the final (working) solution having poor code ergonomics. It's not necessarily that it's wrong, it's that it's awkward or clumsy to understand/use, because my mental model of how it worked didn't take into account the actual practical day to day usage of the code.

I get around that by writing the API first, with usage code examples and all, Or in a GUI app, the UI first. I'll iterate there if needed, and only rewrite internals if it's truly bad or I think it will cause a problem later.

A lot of situations where the code is so nasty I actually have wanted to rewrite... I wind up just throwing it away instead.

Like, one of my happiest days in coding was throwing out some code to support JACK and going all in on Pipewire. Another happy day was replacing some DIY code with a GPL licensed library, deciding that I really didn't need the option to do proprietary stuff anywhere near as much as I wanted less thinking about gstreamer.

"If it's hard to explain, it's probably a bad idea".... If I try a bunch of API variations and I can't come up with anything that doesn't require learning 3 new algorithms to use... Maybe I'm not making a library or an abstraction, I'm making a proof of work hashing scheme that users have to do manually to access an encrypted version of the complexity I'm hiding, and I need to stop before I make z80 assembly in JSON to autogenerate Vue templates that render to cobol.

ALL abstractions are leaky - this is an objectively true statement.

As others said it's not for beauty, it to make sure if there is abstraction it fits the problem. If there is encapsulation it doesn't get in the way. For some coders they can get it on the first try and there is no reason for them to rewrite code. For the rest of us mid coders we need to explore first as well as make sure all cases we desire for Lib/API work.

You're right, I should have been more clear, all abstractions are leaky, but some are right enough most only notice occasionally.

Smart people can ignore ugly code. It's the people who get easily confused that need to see clean and easy to understand code.

Humans always make mistakes and are tired now and then, and the smartest people can still appreciate not needing to solve puzzles just to understand or debug their own code.

Of course clean and readable means very different things to different people, but I don't thing I ever regretted cleaning up code, while I can think of a lot of instances where not doing it wasted a lot of time.

If other people need to read your email/doc/code, then any effort to make it more readable will save them time, regardless of how smart they are.

"If I had more time, I would have written a shorter letter."

Sadly, I think this is true of me — at least of me. I don't think smart people (by this definition) are that common though, so clean code is a sensible default.

There is some point regarding changes on the code where rewriting is less costly or more costly than changing the current code. For me, a big part depends on whether I depend long term or short term on it and how deep I will have to go anyway using it.

I'd rewrite code to make it simpler and easier to hold in one's head, not just to make it pleasing from some aesthetic viewpoint.

Reply on news.ycombinator.com