6 ms·

This is what got me in most sleepless nights, crunch and ass clenching production issues over my career. Simple repetitive shit is easy to reason about, debug

This is what got me in most sleepless nights, crunch and ass clenching production issues over my career. Simple repetitive shit is easy to reason about, debug and onboard people on. Naturally it's balancing act, and modern/popular frameworks are where most people landed, there's been a lot of iteration in this space for decades now.

andix 2y ago
I've made the opposite observation. Without proper abstractions code bases grow like crazy. At some point they are just a huge amount of copy, paste, and slight modification. The amount of code often grows exponentially. With more lines of code comes more effort to maintain it. After a few years those copy and pasted code pieces completely drift apart and create a lot of similar but different issues, that need to be addressed one by one. My approach for designing abstractions is always to make them composable (not this enterprise java inheritance chaos). To allow escaping them when needed.
- Spivak 2y ago
  > At some point they are just a huge amount of copy, paste, and slight modification. I mean is that bad? Unless you keep having to have huge MRs that modify every copy/paste could you just let the code sit there and run forever? I only say this because I've been a maintenance programmer and I could only dream of a codebase like this. The idea that I get a Rollbar with a stack trace and the entirety of what the code actually does is laid bare right at the site of the error in a single file is amazing. And I can change it without affecting anything else?! I end up having to "unwind" all of the abstractions anyway because the nature of the job means I'm not intimately familiar with the codebase and don't just know where the real work happens.
  - notpushkin 2y ago
    There is a balance. Too much abstractions isn’t necessarily better than not enough abstractions. The optimal amount is usually non-zero, though.
    - rafaelmn 2y ago
      But the point is that modern/popular frameworks picked the low hanging fruit of abstraction, we had several iteration cycles over two+ decades of mainstream web tech. The landscape (browser capabilities, backend stacks) has settled over last ten years. We even had time to standardize on things somewhat. Building new abstractions at this point is almost always the wrong move. This is one of the points that LLMs will improve in software dev - they will kill the framework churn because they will work best on stuff already in training data.

andix 2y ago

I've made the opposite observation. Without proper abstractions code bases grow like crazy. At some point they are just a huge amount of copy, paste, and slight modification. The amount of code often grows exponentially. With more lines of code comes more effort to maintain it. After a few years those copy and pasted code pieces completely drift apart and create a lot of similar but different issues, that need to be addressed one by one. My approach for designing abstractions is always to make them composable (not this enterprise java inheritance chaos). To allow escaping them when needed.

Spivak 2y ago
> At some point they are just a huge amount of copy, paste, and slight modification. I mean is that bad? Unless you keep having to have huge MRs that modify every copy/paste could you just let the code sit there and run forever? I only say this because I've been a maintenance programmer and I could only dream of a codebase like this. The idea that I get a Rollbar with a stack trace and the entirety of what the code actually does is laid bare right at the site of the error in a single file is amazing. And I can change it without affecting anything else?! I end up having to "unwind" all of the abstractions anyway because the nature of the job means I'm not intimately familiar with the codebase and don't just know where the real work happens.
- notpushkin 2y ago
  There is a balance. Too much abstractions isn’t necessarily better than not enough abstractions. The optimal amount is usually non-zero, though.
  - rafaelmn 2y ago
    But the point is that modern/popular frameworks picked the low hanging fruit of abstraction, we had several iteration cycles over two+ decades of mainstream web tech. The landscape (browser capabilities, backend stacks) has settled over last ten years. We even had time to standardize on things somewhat. Building new abstractions at this point is almost always the wrong move. This is one of the points that LLMs will improve in software dev - they will kill the framework churn because they will work best on stuff already in training data.