I try to do it as much as possible, especially in code
Complexity is a trap
https://www.joanwestenberg.com/complexity-is-a-trap/
How often do you decomplexify?
To simplify is a true mastery.
Discussion
Do you have your own habits on this?
When I code I always come to a point where I’m going to refactor all the stuff in a more generic way. This often adds abstraction which do simplify things in a technical / more performant way. But to understand all the things (readability), it makes it often more complex. It feels I always have to look for a fair balance.
i've built up a damn near allergy to complexity in code, this is partly why i am a #golang maxi, but also, even in go code, omg some people make things way more difficult than they need to be
and protocols, omg, been swimming in the cesspit of nostr protocol spec for the last year and i've come to some conclusions about how it must be restructured and simplified to improve and standardise across implementations, a lot of simple things that i can roll into a nip, also, and will be, but i'm just going to build the relay side first, and then try and recruit some front end devs to implement the far simpler protocol patterns i have in mind
I think too many people pay too much attention to aesthetics instead of functionality. The way I see it - the code has a functional purpose, it is meant to do something not to look nice or simple so as long as it does what it is useful to someone it is good.
The refactoring process to make code simpler and nicer has nothing to do with its purpose and is s endless endeavor
agree that nicer many times is a trap, but simpler is good.
Refactoring some code to make it simpler can decrease future maintenance, make it easier to find and fix bugs.
For simplicity I mean locality of behaviour and separation of responsibilities.
LoB means that a behaviour should be described and implemented in one single place, avoiding too many layers of indirections that makes it hard for future you (or others) to see the big picture. Every layer of indirection needs to be loaded into your "brain RAM", which takes time and it's lossy. A great quote is "before it runs on a computer, the program needs to run on your brain".
Separation of responsibilities means that a function should only do one thing. For example, one function that implement parsing, one function that validates what has been parsed, one function that process what have been parsed.
This makes it much easier to test code. This is important for me since I use TDD (test driven development), because honestly I am still a noob, so I prefer to test too much than too little.
Btw I fall in love with golang, which is a tremendously simple language with great guardrails, that make it easier to write good idiomatic code from the get go.
my 2 sats about abstraction. I understand the itch about taking some piece of code and making it more general, more abstract, however I try to resist it as much as possible. Why? Because it inevitably adds more complexity, it requires more effort to understand and debug. My rule now is that I abstract only when I have repeated the same code 2 or 3 times.
No-one will be confused by repeated code, which is not the case for an abstraction that doesn't fit or is premature.