3 ms·

>Thank you. This middle ground between hyperscaler infrastructure and super simple web apps is where most of my career has been spent, yet the recent trend is t

>Thank you. This middle ground between hyperscaler infrastructure and super simple web apps is where most of my career has been spent, yet the recent trend is to pretend like there are only two possible extremes: You’re either Facebook or you’re not doing anything complicated. 100% this. I am tired of you don't need microservices, you don't need JWT, you don't need Kubernetes, you don't need ElasticSearch, you don't need IAM, you don't need Redis, you don't need Mongo and everything should stay in one SQL database. Things are being used not because they exist, because people want to be fancy or because they don't have something better to do. Things are being used because they solve problems and do so with least effort possible.

qaq 2y ago
"Things are being used because they solve problems and do so with least effort possible" in an ideal world sure in the real world there are many factors that influence technical decisions often having nothing to do with actual problem being solved
- zimpenfish 2y ago
  Having worked at many places over the last 30 years, yes, there is definitely "resume-driven development" where people pick something they want to put on their resume to solve a problem regardless of its suitability to the task in hand. There's also "blinker-driven development" where people pick the solution based on their own personal set of hammers rather than, again, something more suitable. (There's loads of these though - e.g. "optimisation-driven development" where the solution MUST GO BRRRRR even if the problem could be fixed by Frank typing in "Yes" once a week. "GOF-driven development" where everything has to rigidly fit into a GOF pattern regardless of whether it actually does. "Go-driven development" where everything has to be a interface and you end up reading a method called Validate which calls an interface method Validate which calls an interface method Validate which calls an interface method Validate and you wake up screaming every morning because why just wtf why please help me pleasehelp)
  - sunshinerag 2y ago
    chuckle ... how far did you go into the validate rabbit hole
    - zimpenfish 2y ago
      Thankfully it was only 3 interfaces down. The whole codebase is riddled with the same kind of layering but we do now have guidance about doing stuff like that ("DON'T") and a plan to simplify some of the worst offenders (like the multi-layer `Validate` hell hole.)
  - DeathArrow 2y ago
    If I'd find myself in a place where they do "GOF-driven development" or "Go-driven development" I'd search for another job ASAP. I don't say what you describe doesn't happen, but it's my impression that most people try to adopt solutions that minimize costs and development time (which also translates to money). 99% of the time it's not "do the best thing to satisfy solve this problem" but it's "solve this problem as fast as possible, without adding additional costs and using as few developers as possible".
    - zimpenfish 2y ago
      > "solve this problem as fast as possible, without adding additional costs and using as few developers as possible" Agree with that but from my experience that's more like 20% of the time. The rest is the various kinds of bullshit development where people are padding resumes, having boss's pet hobby horse forced on them, latest shiny flimflam, etc. (A decent chunk of that 30 years has been contracting and that tends to be at places with problems which might be biasing my sample set.)
    - qaq 2y ago
      Well in big orgs people get shuffled around teams so even if you joined a team that is aligned with the way you feel things should be done you might end up in totally different env. after a period of time.
  - 2y ago
rbanffy 2y ago
> everything should stay in one SQL database. At least on different schemas. That and don't let one concern access data from another, or you'll have to coordinate schema changes between those different concerns.

qaq 2y ago

"Things are being used because they solve problems and do so with least effort possible" in an ideal world sure in the real world there are many factors that influence technical decisions often having nothing to do with actual problem being solved

zimpenfish 2y ago
Having worked at many places over the last 30 years, yes, there is definitely "resume-driven development" where people pick something they want to put on their resume to solve a problem regardless of its suitability to the task in hand. There's also "blinker-driven development" where people pick the solution based on their own personal set of hammers rather than, again, something more suitable. (There's loads of these though - e.g. "optimisation-driven development" where the solution MUST GO BRRRRR even if the problem could be fixed by Frank typing in "Yes" once a week. "GOF-driven development" where everything has to rigidly fit into a GOF pattern regardless of whether it actually does. "Go-driven development" where everything has to be a interface and you end up reading a method called Validate which calls an interface method Validate which calls an interface method Validate which calls an interface method Validate and you wake up screaming every morning because why just wtf why please help me pleasehelp)
- sunshinerag 2y ago
  chuckle ... how far did you go into the validate rabbit hole
  - zimpenfish 2y ago
    Thankfully it was only 3 interfaces down. The whole codebase is riddled with the same kind of layering but we do now have guidance about doing stuff like that ("DON'T") and a plan to simplify some of the worst offenders (like the multi-layer `Validate` hell hole.)
- DeathArrow 2y ago
  If I'd find myself in a place where they do "GOF-driven development" or "Go-driven development" I'd search for another job ASAP. I don't say what you describe doesn't happen, but it's my impression that most people try to adopt solutions that minimize costs and development time (which also translates to money). 99% of the time it's not "do the best thing to satisfy solve this problem" but it's "solve this problem as fast as possible, without adding additional costs and using as few developers as possible".
  - zimpenfish 2y ago
    > "solve this problem as fast as possible, without adding additional costs and using as few developers as possible" Agree with that but from my experience that's more like 20% of the time. The rest is the various kinds of bullshit development where people are padding resumes, having boss's pet hobby horse forced on them, latest shiny flimflam, etc. (A decent chunk of that 30 years has been contracting and that tends to be at places with problems which might be biasing my sample set.)
  - qaq 2y ago
    Well in big orgs people get shuffled around teams so even if you joined a team that is aligned with the way you feel things should be done you might end up in totally different env. after a period of time.
- 2y ago

rbanffy 2y ago

> everything should stay in one SQL database. At least on different schemas. That and don't let one concern access data from another, or you'll have to coordinate schema changes between those different concerns.