4 ms·

I think its a meme now to hate abstraction. In big tech I see it as a justification to build parallel systems that do almost the same thing. Abstraction done we

I think its a meme now to hate abstraction. In big tech I see it as a justification to build parallel systems that do almost the same thing. Abstraction done well is where technical leverage comes from. Abstraction done poorly is where technical debt/bad technology comes from. Management prefers the safe route of gating their engineers from abstraction to get the work done with certainty, the trade off being less technical leverage. Its a corporate engineering meme to pin tech workers into being replaceable cogs pumping out low abstraction widgets

BlargMcLarg 4y ago
I wish it was a meme. The things people complained about decades ago are still happening today, and the practitioners are all too eager to turn a 100 line program into a 1000 line one, while taking weeks to test if it does what it should. The average loud dev is a GoF fanatic in love with inaccessible reflection. Double points if their tools are still stuck in a time where stack traces weren't extended to deal with such practices better. And with everything being sliced into pieces: the fun has only just begun
- fdgsdfogijq 4y ago
  Call me blunt, but ive come to the conclusion most people arent intelligent enough to create complex abstractions
  - BlargMcLarg 4y ago
    I don't think intelligence or lack thereof is the problem. Rather, it seems people are paralyzing themselves by enjoying the endless discussions, stakeholder indecision, or boredom. All leading to these grotesque things which lack words in the right places, but have plenty in the wrong places. The average web dev CRUD job isn't interesting enough to warrant that much intelligence.
    - trashtester 4y ago
      Intelligence is definitly a factor. In fact, more often than not when I encounter a person or team that seem to spend their time on everything else except addressing their most important problems, the reason for the apparent procastination is that they simply do not even know how to START solving the problem. This is not exclusive for developers. It happens in management, too. Which is a second source of the problems you describe.
  - bbkane 4y ago
    I'm certainly not. I try to compensate when I can by aggressively rewriting until an abstraction stops breaking things and feels natural
  - adamrezich 4y ago
    my experience is quite the opposite, it's much more difficult to create a simple abstraction as opposed to an overengineered and/or overgeneralized one.
    - fdgsdfogijq 4y ago
      complex != overengineered and/or overgeneralized one some technical problems are actually just complex
      - adamrezich 4y ago
        sure, but it's easier to solve a complex problem by building an abstraction that is more complex than the problem requires, that to build an abstraction that is as simple as possible (given the complexity inherent to the problem). then, once you have your too-complex abstraction, it can be difficult to restrain yourself, especially as an eager junior developer, to not take your amazing feat of abstraction engineering to its logical, generalized conclusion... or at least die trying. "see, now, every time I want to do x, all I have to do is y and z, instead of a, b, c, and d" is an incredibly addictive drug! (I write this as a recovering addict.)
        fdgsdfogijq 4y ago
        right, but my point is thats what we call a bad software developer. and most software developers are warned, because real abstraction is beyond their capability. a world class software engineer knows that maxim, but also is capable of building an abstraction that lasts.
  - trashtester 4y ago
    Every person have a limit on how complex abstractions they're able to properly create. Then there is another, usually lower, limit for what kind of abstraction they're able to understand well enough to make use of it. In a lot of cases, people try to leverage abstractions above that second level (for them), in which case they're simply imitating in a cargo cult manner some abstraction that will often not work well if not properly understood. This is where the atrocities start, imo. And the sad part is that many of these programmers do have a fairly good understanding of the business needs of the stuff they're making, and often those things are quite simple from a technical perspective. Programmers that might have been able to create perfectly usable apps in VB or something similar 20 years ago, are now only churning out useless garbage in some moder cloud based stack. (Or, at bes,t are using 80% of their time struggling with their tech, while with a simpler setup, they could have spend only 20% on the tech and used 80% of their attention on addressing business needs.)
  - civopsec 4y ago
    Call me blunt, but this statement feels about as hard-hitting and impactful as someone shouting in a crowd that they like pastrami sandwiches.
- auggierose 4y ago
  GoF = Game of Failure?
  - gpderetta 4y ago
    Gang of Four, as the authors of the Design Patterns book are known (and by extension the book itself).
    - auggierose 4y ago
      Oh right, that book is so old, I forgot that it ever existed ...
- TurboHaskal 4y ago
  I blame GoF for giving us the two worst decades in software. But in my experience, the average loud dev has mutated into the TDD + DDD fanatic. These insufferable simpletons won't only criticize your end result when it doesn't align well with their preferred abstractions but also tell you _how_ to reach that end. Something is also brewing with functional concepts and category theory trickling down... and it doesn't smell good.
Buttons840 4y ago
> Abstraction done poorly is where technical debt/bad technology comes from. I agree, but it is not the only source of technical debt. I tried to work on a batch job that ran a company one time, it was just a top to bottom script, if-statements, loops, etc... nested 17 (!) deep in places: an if inside a for loop inside a while loop inside an if inside an if inside a while loop inside an if inside a for loop inside a while loop inside an if, etc. The guy who wrote it didn't know what a function was. Believe me, you can have technical debt even without abstraction. One of my frustrations is that it takes a lot of skill to rise above "big pile of if-statements" programming, and it's so easy for a good abstraction to crumble back into a "pile of if-statements" if even one developer working on it doesn't understand the abstraction.

BlargMcLarg 4y ago

I wish it was a meme. The things people complained about decades ago are still happening today, and the practitioners are all too eager to turn a 100 line program into a 1000 line one, while taking weeks to test if it does what it should. The average loud dev is a GoF fanatic in love with inaccessible reflection. Double points if their tools are still stuck in a time where stack traces weren't extended to deal with such practices better. And with everything being sliced into pieces: the fun has only just begun

fdgsdfogijq 4y ago
Call me blunt, but ive come to the conclusion most people arent intelligent enough to create complex abstractions
- BlargMcLarg 4y ago
  I don't think intelligence or lack thereof is the problem. Rather, it seems people are paralyzing themselves by enjoying the endless discussions, stakeholder indecision, or boredom. All leading to these grotesque things which lack words in the right places, but have plenty in the wrong places. The average web dev CRUD job isn't interesting enough to warrant that much intelligence.
  - trashtester 4y ago
    Intelligence is definitly a factor. In fact, more often than not when I encounter a person or team that seem to spend their time on everything else except addressing their most important problems, the reason for the apparent procastination is that they simply do not even know how to START solving the problem. This is not exclusive for developers. It happens in management, too. Which is a second source of the problems you describe.
- bbkane 4y ago
  I'm certainly not. I try to compensate when I can by aggressively rewriting until an abstraction stops breaking things and feels natural
- adamrezich 4y ago
  my experience is quite the opposite, it's much more difficult to create a simple abstraction as opposed to an overengineered and/or overgeneralized one.
  - fdgsdfogijq 4y ago
    complex != overengineered and/or overgeneralized one some technical problems are actually just complex
    - adamrezich 4y ago
      sure, but it's easier to solve a complex problem by building an abstraction that is more complex than the problem requires, that to build an abstraction that is as simple as possible (given the complexity inherent to the problem). then, once you have your too-complex abstraction, it can be difficult to restrain yourself, especially as an eager junior developer, to not take your amazing feat of abstraction engineering to its logical, generalized conclusion... or at least die trying. "see, now, every time I want to do x, all I have to do is y and z, instead of a, b, c, and d" is an incredibly addictive drug! (I write this as a recovering addict.)
      - fdgsdfogijq 4y ago
        right, but my point is thats what we call a bad software developer. and most software developers are warned, because real abstraction is beyond their capability. a world class software engineer knows that maxim, but also is capable of building an abstraction that lasts.
- trashtester 4y ago
  Every person have a limit on how complex abstractions they're able to properly create. Then there is another, usually lower, limit for what kind of abstraction they're able to understand well enough to make use of it. In a lot of cases, people try to leverage abstractions above that second level (for them), in which case they're simply imitating in a cargo cult manner some abstraction that will often not work well if not properly understood. This is where the atrocities start, imo. And the sad part is that many of these programmers do have a fairly good understanding of the business needs of the stuff they're making, and often those things are quite simple from a technical perspective. Programmers that might have been able to create perfectly usable apps in VB or something similar 20 years ago, are now only churning out useless garbage in some moder cloud based stack. (Or, at bes,t are using 80% of their time struggling with their tech, while with a simpler setup, they could have spend only 20% on the tech and used 80% of their attention on addressing business needs.)
- civopsec 4y ago
  Call me blunt, but this statement feels about as hard-hitting and impactful as someone shouting in a crowd that they like pastrami sandwiches.
auggierose 4y ago
GoF = Game of Failure?
- gpderetta 4y ago
  Gang of Four, as the authors of the Design Patterns book are known (and by extension the book itself).
  - auggierose 4y ago
    Oh right, that book is so old, I forgot that it ever existed ...
TurboHaskal 4y ago
I blame GoF for giving us the two worst decades in software. But in my experience, the average loud dev has mutated into the TDD + DDD fanatic. These insufferable simpletons won't only criticize your end result when it doesn't align well with their preferred abstractions but also tell you _how_ to reach that end. Something is also brewing with functional concepts and category theory trickling down... and it doesn't smell good.

Buttons840 4y ago

> Abstraction done poorly is where technical debt/bad technology comes from. I agree, but it is not the only source of technical debt. I tried to work on a batch job that ran a company one time, it was just a top to bottom script, if-statements, loops, etc... nested 17 (!) deep in places: an if inside a for loop inside a while loop inside an if inside an if inside a while loop inside an if inside a for loop inside a while loop inside an if, etc. The guy who wrote it didn't know what a function was. Believe me, you can have technical debt even without abstraction. One of my frustrations is that it takes a lot of skill to rise above "big pile of if-statements" programming, and it's so easy for a good abstraction to crumble back into a "pile of if-statements" if even one developer working on it doesn't understand the abstraction.