2 ms·

One of the very first times I was paid to professionally develop software for someone else I totally fucked it up by trying to build some kind of “modular” “reu

One of the very first times I was paid to professionally develop software for someone else I totally fucked it up by trying to build some kind of “modular” “reusable” contraption, that in reality was a vague collection of ill-defined ideas for what I wanted to make. I have since come to believe that this is a trap that many people fall into. Even a colleague of mine at my current job might be sort of in this track himself at the moment I think. And I don’t feel that he is interested in listening to me at all. Even though we are supposedly on the same team. I think these kinds of things, when you fall into the trap, is something that you have to eventually realise on your own why it was a bad idea. Meanwhile I am at the verge of quitting because I find it frustrating that we are working on this thing where it seems I am not being listened to and we are implementing something in a way that I recognise from my own past mistakes as a patently poor way of going about things. But at the same time, I love the company I work for, and the pay is really good, and I am scared that if I quit I won’t find another job for a long time that will pay well enough to support myself and my girlfriend and our expenses. Anyway. Point is, I agree with you, there will always be people trying to build these frameworks and what have you.

klabb3 3y ago
Overengineering confessions. He that is without sin among you, let him cast the first stone at her. There’s a seductive aspect to abstraction and generalization. But I don’t even think that’s what makes these things so bad in practice. It’s other, more trivial things, like losing stack traces, imposing of types and flow control that the author didn’t anticipate, but pains the user tremendously. We don’t really have good measurements for - and often overlook those aspects - which causes us collectively to suffer only after a great commitment of time and labor. I’m pretty convinced that complexity isn’t just mentally confusing but actually hard measurable, as long as we have language to describe it and a well tuned skepticism towards unnecessary layers of indirection. Function coloring is one such attempt, imo, at explaining the great costs of something which looks innocent.
- paiute 3y ago
  Good abstraction is the foundation for most of what we do. Bad abstraction is worse than no abstraction. Not everything needs to be abstracted. Ontology is bad abstraction (is a has a stuff). Some people are bad at abstraction and some people are bad at writing business code; Both can be good coders.
  - klabb3 3y ago
    > Ontology is bad abstraction (is a has a stuff). Is “can do X” included in that definition (ie are you alluding to composition vs inheritance)? Can you elaborate on what constitutes good abstraction, in your book?
franciscop 3y ago
Exactly, that's one of the reasons I'm so happy where JS is as an indie dev (def not professionally though). JS has gone through so many "you need a factory factory factory", and now we have gone back to basic principles. A few examples I've lived: - Browser incompatibilities. You couldn't just do X, because in other browsers X might behave differently. So you would write X blueprint and use an X factory that would auto-generate code for the different browsers. This applies to both JS, CSS and HTML BTW. - Then the modules+bundlers came. Initially they were <script>, but when you had multiple you wanted to concatenate them for performance ofc, and in Node.js you wanted a way to import them. So a tool for each was created, then a tool on top of both was created, and thus a factory of factories of sorts was created. - Then ES6+ came, which was similar to the first point so I won't bother you with it. - Then Webpack and all of its derivates promised to solve all of the problems above, at the same time (with Babel and whatnot), and the era of mega-factories came to be. Luckily nowadays we have standardize mostly around ES6+, and using ESM for imports/exports everywhere, so if you write plain JS and use ESM both in your code and in library code you don't need any more factories. You can still use a tool to bundle all your code, or to use more advanced coding paradigms like React*, but that's nowhere the peak of complexity we've lived. That's one of the reasons I dislike TS BTW, because now that we are in "bliss plain JS" some people were not happy and had to add complex tooling again with TS. *I draw the line here and declare that JSX is not JS, and thus this complexity thing doesn't apply there. If you are writing JSX you are writing it against CRA/Vite/Next, while plain JS you are writing it against the browser, so only things built on top of JSX, like TSX, can be considered factories from that point of view. If you think it's not fair, I'll argue it's as fair as JS, since in the end every browser is a "factory" of JS -> low-level code.

klabb3 3y ago

Overengineering confessions. He that is without sin among you, let him cast the first stone at her. There’s a seductive aspect to abstraction and generalization. But I don’t even think that’s what makes these things so bad in practice. It’s other, more trivial things, like losing stack traces, imposing of types and flow control that the author didn’t anticipate, but pains the user tremendously. We don’t really have good measurements for - and often overlook those aspects - which causes us collectively to suffer only after a great commitment of time and labor. I’m pretty convinced that complexity isn’t just mentally confusing but actually hard measurable, as long as we have language to describe it and a well tuned skepticism towards unnecessary layers of indirection. Function coloring is one such attempt, imo, at explaining the great costs of something which looks innocent.

paiute 3y ago
Good abstraction is the foundation for most of what we do. Bad abstraction is worse than no abstraction. Not everything needs to be abstracted. Ontology is bad abstraction (is a has a stuff). Some people are bad at abstraction and some people are bad at writing business code; Both can be good coders.
- klabb3 3y ago
  > Ontology is bad abstraction (is a has a stuff). Is “can do X” included in that definition (ie are you alluding to composition vs inheritance)? Can you elaborate on what constitutes good abstraction, in your book?

franciscop 3y ago

Exactly, that's one of the reasons I'm so happy where JS is as an indie dev (def not professionally though). JS has gone through so many "you need a factory factory factory", and now we have gone back to basic principles. A few examples I've lived: - Browser incompatibilities. You couldn't just do X, because in other browsers X might behave differently. So you would write X blueprint and use an X factory that would auto-generate code for the different browsers. This applies to both JS, CSS and HTML BTW. - Then the modules+bundlers came. Initially they were <script>, but when you had multiple you wanted to concatenate them for performance ofc, and in Node.js you wanted a way to import them. So a tool for each was created, then a tool on top of both was created, and thus a factory of factories of sorts was created. - Then ES6+ came, which was similar to the first point so I won't bother you with it. - Then Webpack and all of its derivates promised to solve all of the problems above, at the same time (with Babel and whatnot), and the era of mega-factories came to be. Luckily nowadays we have standardize mostly around ES6+, and using ESM for imports/exports everywhere, so if you write plain JS and use ESM both in your code and in library code you don't need any more factories. You can still use a tool to bundle all your code, or to use more advanced coding paradigms like React*, but that's nowhere the peak of complexity we've lived. That's one of the reasons I dislike TS BTW, because now that we are in "bliss plain JS" some people were not happy and had to add complex tooling again with TS. *I draw the line here and declare that JSX is not JS, and thus this complexity thing doesn't apply there. If you are writing JSX you are writing it against CRA/Vite/Next, while plain JS you are writing it against the browser, so only things built on top of JSX, like TSX, can be considered factories from that point of view. If you think it's not fair, I'll argue it's as fair as JS, since in the end every browser is a "factory" of JS -> low-level code.