4 ms·

Not to derail too much from the original article, but I've been starting to feel the same about entire tech stacks. Building CRUD apps is annoying no matter wha

Not to derail too much from the original article, but I've been starting to feel the same about entire tech stacks. Building CRUD apps is annoying no matter what. Every time a framework makes one thing easy, it makes a couple of other things hard. No matter what tech you're using, there are some generalizable skills that are indispensable for project longevity: good testing, organization of files, consistency in concepts, and thoughtful comments that tell you why things are the way they are. The idea that we can replace skillful software engineering with the right abstraction just hasn't panned out for me.

thehappypm 4y ago
Mechanical engineers don’t attempt to have “one part that does everything”. Maybe we should think more like them.
- chii 4y ago
  well, they don't have a silver bullet part, but there are standardized components like screws, gears, levers etc. It's just that mechanical engineering is constrained by physical laws, and that gives design constraints that don't exist in software.
  - wtetzner 4y ago
    Standardized parts sound a lot like libraries implementing common interfaces.
- carlmr 4y ago
  Libraries over frameworks. It's that simple. Frameworks always make something hard the initial authors didn't think about. That happens a lot. Libraries provide some small set of well-tested functionalities, which you can replace if they don't serve you well. Every framework I've worked with had some issues, and because it's a framework it becomes a herculean effort to switch to something else. If it's only a single functionality that's much easier.
  - bosie 4y ago
    While I agree, I always find picking tens of libraries for a project and making sure the dependencies work out to be somewhat difficult. What would be the way to orchestrate those libraries? Some sort of orchestration library?
    - resonious 4y ago
      I think "orchestratability" is a property of a library. If you start using a library and you find it hard to make it play nicely with other libs, it's probably not a well-designed library.
      - Ygg2 4y ago
        So you introduce a layer for interoperability. And now your library perf has tanked.
        DiggyJohnson 4y ago
        I don’t see how this comment makes sense in context. Surely GP isn’t suggesting that you include an additional tool to orchestrate library dependencies, but to choose libraries that don’t have complex dependency burdens.
        Ygg2 4y ago
        If you want two incompatible tools to work you need an abstraction. However because of extra layer of abstraction you suffer performance loss.
  - sshine 4y ago
    > Libraries over frameworks. I currently maintain a minimalistic website, and using a static site generator has been golden. I consider that a framework. The moment I need to do anything the framework author didn't think of, I'll end up spending hours. But because I make so few changes, the bulk of the website content is Markdown, and the very limited styling is done with the HTML/CSS templating system. Basically, because this website is a low priority, anything that proves complicated is a bad investment. A framework is great here.
- CipherThrowaway 4y ago
  The mechanical engineers at my work can barely use a computer. I think I'm good.
- conradfr 4y ago
  That's how you spend days debugging npm dependency hell between libraries instead of coding with your framework of choice.
- maccard 4y ago
  Have you see how modern cars are built? This [0] is a marketing blog but explains pretty well that in fact they do lean heavily into the "reuse the thing for all the things" [0] https://www.carexpert.com.au/car-news/platform-sharing-the-many-faces-of-mqb https://www.carexpert.com.au/car-news/platform-sharing-the-m...
postalrat 4y ago
You are still looking for the right abstractions just not in the code that makes the application work.
mieubrisse 4y ago
Shameless self-promotion: this is exactly the problem our team hit and is trying to solve at kurtosistech.com. It still Just Sucks to build microservices because you need to know a) what you need to write b) what components you need to glue together (do I want a Dockerfile? what testing framework? what CI/CD?) and c) how to actually implement them (how do I write my Github Actions config? how do Dockerifles work again?). The Kurtosis hypothesis is that we can abstract away most of these things with automation (e.g. force devs to update the changelog, force versioning of the API, handle all the automated client generation) while still allowing users to pop the hood and do the low-level if they really need to (but popping the hood shouldn't be easy).
- erulabs 4y ago
  Just a bit of feedback: micro service architecture isn’t universally hated (I love my Skaffold setup), and “popping the hood shouldn’t be easy” makes the devops engineer inside of me want to refuse to even read more about your product on principle. If you’re not building a tool for junior developers only, you might want to change the tone of your pitch to more of a “we make this super slick” instead of “we built black box #93784583”

thehappypm 4y ago

Mechanical engineers don’t attempt to have “one part that does everything”. Maybe we should think more like them.

chii 4y ago
well, they don't have a silver bullet part, but there are standardized components like screws, gears, levers etc. It's just that mechanical engineering is constrained by physical laws, and that gives design constraints that don't exist in software.
- wtetzner 4y ago
  Standardized parts sound a lot like libraries implementing common interfaces.
carlmr 4y ago
Libraries over frameworks. It's that simple. Frameworks always make something hard the initial authors didn't think about. That happens a lot. Libraries provide some small set of well-tested functionalities, which you can replace if they don't serve you well. Every framework I've worked with had some issues, and because it's a framework it becomes a herculean effort to switch to something else. If it's only a single functionality that's much easier.
- bosie 4y ago
  While I agree, I always find picking tens of libraries for a project and making sure the dependencies work out to be somewhat difficult. What would be the way to orchestrate those libraries? Some sort of orchestration library?
  - resonious 4y ago
    I think "orchestratability" is a property of a library. If you start using a library and you find it hard to make it play nicely with other libs, it's probably not a well-designed library.
    - Ygg2 4y ago
      So you introduce a layer for interoperability. And now your library perf has tanked.
      - DiggyJohnson 4y ago
        I don’t see how this comment makes sense in context. Surely GP isn’t suggesting that you include an additional tool to orchestrate library dependencies, but to choose libraries that don’t have complex dependency burdens.
        Ygg2 4y ago
        If you want two incompatible tools to work you need an abstraction. However because of extra layer of abstraction you suffer performance loss.
- sshine 4y ago
  > Libraries over frameworks. I currently maintain a minimalistic website, and using a static site generator has been golden. I consider that a framework. The moment I need to do anything the framework author didn't think of, I'll end up spending hours. But because I make so few changes, the bulk of the website content is Markdown, and the very limited styling is done with the HTML/CSS templating system. Basically, because this website is a low priority, anything that proves complicated is a bad investment. A framework is great here.
CipherThrowaway 4y ago
The mechanical engineers at my work can barely use a computer. I think I'm good.
conradfr 4y ago
That's how you spend days debugging npm dependency hell between libraries instead of coding with your framework of choice.
maccard 4y ago
Have you see how modern cars are built? This [0] is a marketing blog but explains pretty well that in fact they do lean heavily into the "reuse the thing for all the things" [0] https://www.carexpert.com.au/car-news/platform-sharing-the-many-faces-of-mqb https://www.carexpert.com.au/car-news/platform-sharing-the-m...

postalrat 4y ago

You are still looking for the right abstractions just not in the code that makes the application work.

mieubrisse 4y ago

Shameless self-promotion: this is exactly the problem our team hit and is trying to solve at kurtosistech.com. It still Just Sucks to build microservices because you need to know a) what you need to write b) what components you need to glue together (do I want a Dockerfile? what testing framework? what CI/CD?) and c) how to actually implement them (how do I write my Github Actions config? how do Dockerifles work again?). The Kurtosis hypothesis is that we can abstract away most of these things with automation (e.g. force devs to update the changelog, force versioning of the API, handle all the automated client generation) while still allowing users to pop the hood and do the low-level if they really need to (but popping the hood shouldn't be easy).

erulabs 4y ago
Just a bit of feedback: micro service architecture isn’t universally hated (I love my Skaffold setup), and “popping the hood shouldn’t be easy” makes the devops engineer inside of me want to refuse to even read more about your product on principle. If you’re not building a tool for junior developers only, you might want to change the tone of your pitch to more of a “we make this super slick” instead of “we built black box #93784583”