5 ms·

No, it definitely has got worse, I've been doing this 15 years, the sweet spot was the Rails revolution. Before that a lot of frameworks were a bit too much mag

No, it definitely has got worse, I've been doing this 15 years, the sweet spot was the Rails revolution. Before that a lot of frameworks were a bit too much magic, and not enough understanding of how browsers, http and html worked. Simple MVC stacks went to all languages, jQuery front-ends doing enough but not a lot. JavaScript enhanced easy to reason about server-side stacks. You used to spend a couple of days a year, yes YEAR, mucking around with tooling. Now it wouldn't be too much of an exaggeration to say you spend a day or so a week fighting some part of your stack because it's been over-engineered. IDEs can't keep up so you have to run inscrutable command line tools that fail if you have deviated even slightly from whatever error-prone rain-dance some moron claiming 'best practice' has forced into the build process. Programming used to be about writing code to solve business problems. The shift to DevOps has been a massive productivity drain and most stacks are now incredibly brittle. The worse part has been debugging, which you touch upon. Native calls, simple call stacks, easy error logging. All gone. Moving everything into hard to debug http calls has been a disastrous productivity sink. The irony has been that as languages have got significantly better our productivity has actually dropped massively because of the ridiculous amounts of over-engineering in "modern" code bases. I recently worked on a project with 2 devs that took 3 months with a modern stack. The prototype in a standard MVC stack I'd made to demo to the client took 2 days. It's utterly ridiculous and sometimes I feel like the boy in the story about the emperor with no clothes.

bko 4y ago
> I recently worked on a project with 2 devs that took 3 months with a modern stack. The prototype in a standard MVC stack I'd made to demo to the client took 2 days. Can you expand on the modern stack and that standard stack? Is the "standard stack" you propose easier to work with now than it was 15 years ago? I guess the "standard stack" is just out of fashion? My preferred stack (aws serverless BE, nextjs front end or just aws app sync) keeps me in one language (typescript), with some stuff like GraphQL that you have to know. But the tooling around that helps keep my errors in compile time for the most part.
- pc86 4y ago
  Is being in one language really that much of a benefit? I've worked on several large production apps with node backends and I'd rather use almost any other backend language. And I take issue with saying you "have to know" GraphQL, that's a pretty specialized tool for pretty specific problems. Most things are not graph structures.
  - jokethrowaway 4y ago
    Maybe I'm biased because I've been using node.js for 10+ years but node.js has a decent API. Simple, slightly opinionated. You just need to be careful of dependencies and what kool kids are doing these days. GraphQL is a complete nightmare. If you don't transpile anything and are conservative with your dependency you're golden.
- mattmanser 4y ago
  In that case it was a simple .Net core MVC stack, Vs an angular/Web API stack. For some inscrutable reason you can no longer do a simple 3 page form with a results page without making a SPA these days without getting someone claiming you're doing it wrong, it's nuts. Worse still, the angular app has all sorts of weird bugs. Auto-complete somehow screws with the validation of inputs, back button doesn't work properly as you lose all your data, URLs dont work, etc., etc., etc. There's also all sorts of craziness like the whole admin frontend is bundled with the client-facing part as the front-end developer didn't know how to split them up. Utterly preposterous. The problem is often that very skilled Devs give advice about incredibly specific stacks that only someone of their abnormally high-skill level can maintain. Throw in a few juniors or a few mediocre developers and the whole project turns into a complete and utter mess. And don't get me started on your stack that's mainly inappropriate for most applications. GraphQL. Talk about the next NoSQL fiasco in the making. Perhaps you missed the whole saga of everyone doing new development in NoSQL and then a few years later we had the flurry of blog posts about "Why are we losing data? I didn't realize ACID was so important..."
  - native_samples 4y ago
    What is it you don't like about GraphQL? It seems to do what it was designed to do pretty well. I take it the issue is more with the pseudo-databases it's used as a front-end for?
biorach 4y ago
People still do deploy production ready systems using RoR, Django/Python or whatever "sweet spot" framework you want to mention. Some run quite successful businesses. You can't generalise from your experience over the last few months. > Programming used to be about writing code to solve business problems. The shift to DevOps has been a massive productivity drain and most stacks are now incredibly brittle. Some businesses _have_ to "shift to DevOps" in order to operate at the scale and resilience required. Some businesses have unnecessarily migrated to over engineered infrastructure because monkey see monkey do. Saying "everything is ruined" completely misses the dynamic. As an earlier poster explained there are a lot more tools in the box now. Making the right choice requires experience, a good understanding of the problem to be solved and discipline in implementation. Get it wrong one way and you end up with an over-engineered mess that takes forever to get work done with. Get it wrong another way and you end up overwhelmed by traffic, unable to scale in response and forever fighting fires.
- tomc1985 4y ago
  God I am sick of these apologetics every time someone expresses skepticism. > Get it wrong another way and you end up overwhelmed by traffic, unable to scale in response and forever fighting fires. To nitpick this specifically, over my 12-year career toiling over this stuff there has never been a scenario where this has required a radical rework to solve. Boring-ass B2B shit rarely requires that level of engineering and, at least in my case, the workloads were fairly predictable and increased in a linear fashion. The one time I did accidentally end of DDoSing ourselves, I temporarily stood up nginx instead of our aging Apache install and was able to serve enough requests to fix the problem. (We then transitioned our app to run in nginx) It was one fire, and it took a little bit of brainpower to fix. Then the DO droplets were humming along perfectly, and last I heard they continue to do so to this day. The operational aspects of this double-digit-millions-per-year business ran on a postgres database that compressed to 6gb. The next business I worked for did billions per year in business value and, until HQ mandated migrating everything to GCP, was humming along perfectly fine on Heroku for a monthly spend well under five digits. Ironically, I think they initially wanted us to be on-prem but couldn't support our stack and would have left all of that to our devops guys. GCP was the compromise (oof!).
pc86 4y ago
Serious question - if it was so much better then, why are approximately zero new companies building a Laravel/Rails/whatever app and using jQuery for the front end? If it's that much of an advantage I would expect at least someone who is trying that (because surely some are) to succeed with their lean, mean tech stack. Why wouldn't you have just written the project in that standard MVC stack instead of a modern one? You won't get any objection from me on the debugging point, it's much harder, especially when you're crossing environment - e.g. running the front end locally but maybe hitting a remote dev or QA backend. I will point out though that there are logging tools that support the pretty standard practice of having correlation/transaction/trace IDs on your requests, such that you put in a GUID from an error and it shows you the entire request and anything that request spawned.
- jokethrowaway 4y ago
  Indie makers famously do just that. Pieter Levels is making millions with PHP and jQuery. I consult primarily in node and react with all sorts of transpilers mess and shitty packers. The stuff of nightmares - we waste so much time making things work - but simplifying the stack will never get traction among the not-anymore-technical principal engineers or even amongst the other developers who need a fancy cv for their next gig. My side businesses use python, django, jQuery, old node.js without modules, rust, svelte. Engineers hired in big companies want to work on shiny technologies and build their cv.
  - ushakov 4y ago
    > Pieter Levels is making millions with PHP and jQuery no, the reason Pieter Levels makes millions is not PHP and jQuery, but because he's also a brilliant sales/marketing/business person
    - NateEag 4y ago
      OP didn't say PHP and jQuery were why Pieter Levels is making millions - just that they're tools he's using to do it. Ergo, they are at least fit for that purpose. They aren't bad enough to prevent him from making millions.
cgh 4y ago
Your comment seems to imply that computer programming == web development. Would you say your comments also apply to embedded, mobile, games, data science/ML and scientific computing?
mcluck 4y ago
> The worse part has been debugging, which you touch upon. Native calls, simple call stacks, easy error logging. All gone. > Moving everything into hard to debug http calls has been a disastrous productivity sink. There are a lot of good things coming out of the latest big experiments but this has been a major blow. I have worked on software where the intended debugging approach was to write some code, manually push it out to a shared dev environment, read CloudWatch logs for debugging. It is by far the worst way to debug code that I have ever seen. Things that would take me minutes to debug in a normal setup can take hours or days. Projects like LocalStack aim to improve this a little bit but it's completely counter to the ethos of many "cloud-first" developers.
l30n4da5 4y ago
> Moving everything into hard to debug http calls has been a disastrous productivity sink. I'll admit for the vast majority of web apps out there, this is not needed, but there is definitely a scalability concern if your entire stack is a single ruby on rails mvc application.
- sparker72678 4y ago
  This is the misconception that will just never die. I've worked on multiple products with 1 million+ users running on stock Rails MVC backends. Everything scales just fine. Until you hit a DB hardware limit you can just keep adding more web instances behind your load balancer. And DB Hardware limits these days are astronomical. If you're actually hitting the limit of scaling our web backends horizontally and you don't have the money to deal with the problem, you might need to take a hard look at your product. And I'm confident this is true for whatever your backend is: Django, Rails, Laravel, whatever.

bko 4y ago

> I recently worked on a project with 2 devs that took 3 months with a modern stack. The prototype in a standard MVC stack I'd made to demo to the client took 2 days. Can you expand on the modern stack and that standard stack? Is the "standard stack" you propose easier to work with now than it was 15 years ago? I guess the "standard stack" is just out of fashion? My preferred stack (aws serverless BE, nextjs front end or just aws app sync) keeps me in one language (typescript), with some stuff like GraphQL that you have to know. But the tooling around that helps keep my errors in compile time for the most part.

pc86 4y ago
Is being in one language really that much of a benefit? I've worked on several large production apps with node backends and I'd rather use almost any other backend language. And I take issue with saying you "have to know" GraphQL, that's a pretty specialized tool for pretty specific problems. Most things are not graph structures.
- jokethrowaway 4y ago
  Maybe I'm biased because I've been using node.js for 10+ years but node.js has a decent API. Simple, slightly opinionated. You just need to be careful of dependencies and what kool kids are doing these days. GraphQL is a complete nightmare. If you don't transpile anything and are conservative with your dependency you're golden.
mattmanser 4y ago
In that case it was a simple .Net core MVC stack, Vs an angular/Web API stack. For some inscrutable reason you can no longer do a simple 3 page form with a results page without making a SPA these days without getting someone claiming you're doing it wrong, it's nuts. Worse still, the angular app has all sorts of weird bugs. Auto-complete somehow screws with the validation of inputs, back button doesn't work properly as you lose all your data, URLs dont work, etc., etc., etc. There's also all sorts of craziness like the whole admin frontend is bundled with the client-facing part as the front-end developer didn't know how to split them up. Utterly preposterous. The problem is often that very skilled Devs give advice about incredibly specific stacks that only someone of their abnormally high-skill level can maintain. Throw in a few juniors or a few mediocre developers and the whole project turns into a complete and utter mess. And don't get me started on your stack that's mainly inappropriate for most applications. GraphQL. Talk about the next NoSQL fiasco in the making. Perhaps you missed the whole saga of everyone doing new development in NoSQL and then a few years later we had the flurry of blog posts about "Why are we losing data? I didn't realize ACID was so important..."
- native_samples 4y ago
  What is it you don't like about GraphQL? It seems to do what it was designed to do pretty well. I take it the issue is more with the pseudo-databases it's used as a front-end for?

biorach 4y ago

People still do deploy production ready systems using RoR, Django/Python or whatever "sweet spot" framework you want to mention. Some run quite successful businesses. You can't generalise from your experience over the last few months. > Programming used to be about writing code to solve business problems. The shift to DevOps has been a massive productivity drain and most stacks are now incredibly brittle. Some businesses _have_ to "shift to DevOps" in order to operate at the scale and resilience required. Some businesses have unnecessarily migrated to over engineered infrastructure because monkey see monkey do. Saying "everything is ruined" completely misses the dynamic. As an earlier poster explained there are a lot more tools in the box now. Making the right choice requires experience, a good understanding of the problem to be solved and discipline in implementation. Get it wrong one way and you end up with an over-engineered mess that takes forever to get work done with. Get it wrong another way and you end up overwhelmed by traffic, unable to scale in response and forever fighting fires.

tomc1985 4y ago
God I am sick of these apologetics every time someone expresses skepticism. > Get it wrong another way and you end up overwhelmed by traffic, unable to scale in response and forever fighting fires. To nitpick this specifically, over my 12-year career toiling over this stuff there has never been a scenario where this has required a radical rework to solve. Boring-ass B2B shit rarely requires that level of engineering and, at least in my case, the workloads were fairly predictable and increased in a linear fashion. The one time I did accidentally end of DDoSing ourselves, I temporarily stood up nginx instead of our aging Apache install and was able to serve enough requests to fix the problem. (We then transitioned our app to run in nginx) It was one fire, and it took a little bit of brainpower to fix. Then the DO droplets were humming along perfectly, and last I heard they continue to do so to this day. The operational aspects of this double-digit-millions-per-year business ran on a postgres database that compressed to 6gb. The next business I worked for did billions per year in business value and, until HQ mandated migrating everything to GCP, was humming along perfectly fine on Heroku for a monthly spend well under five digits. Ironically, I think they initially wanted us to be on-prem but couldn't support our stack and would have left all of that to our devops guys. GCP was the compromise (oof!).

pc86 4y ago

Serious question - if it was so much better then, why are approximately zero new companies building a Laravel/Rails/whatever app and using jQuery for the front end? If it's that much of an advantage I would expect at least someone who is trying that (because surely some are) to succeed with their lean, mean tech stack. Why wouldn't you have just written the project in that standard MVC stack instead of a modern one? You won't get any objection from me on the debugging point, it's much harder, especially when you're crossing environment - e.g. running the front end locally but maybe hitting a remote dev or QA backend. I will point out though that there are logging tools that support the pretty standard practice of having correlation/transaction/trace IDs on your requests, such that you put in a GUID from an error and it shows you the entire request and anything that request spawned.

jokethrowaway 4y ago
Indie makers famously do just that. Pieter Levels is making millions with PHP and jQuery. I consult primarily in node and react with all sorts of transpilers mess and shitty packers. The stuff of nightmares - we waste so much time making things work - but simplifying the stack will never get traction among the not-anymore-technical principal engineers or even amongst the other developers who need a fancy cv for their next gig. My side businesses use python, django, jQuery, old node.js without modules, rust, svelte. Engineers hired in big companies want to work on shiny technologies and build their cv.
- ushakov 4y ago
  > Pieter Levels is making millions with PHP and jQuery no, the reason Pieter Levels makes millions is not PHP and jQuery, but because he's also a brilliant sales/marketing/business person
  - NateEag 4y ago
    OP didn't say PHP and jQuery were why Pieter Levels is making millions - just that they're tools he's using to do it. Ergo, they are at least fit for that purpose. They aren't bad enough to prevent him from making millions.

cgh 4y ago

Your comment seems to imply that computer programming == web development. Would you say your comments also apply to embedded, mobile, games, data science/ML and scientific computing?

mcluck 4y ago

> The worse part has been debugging, which you touch upon. Native calls, simple call stacks, easy error logging. All gone. > Moving everything into hard to debug http calls has been a disastrous productivity sink. There are a lot of good things coming out of the latest big experiments but this has been a major blow. I have worked on software where the intended debugging approach was to write some code, manually push it out to a shared dev environment, read CloudWatch logs for debugging. It is by far the worst way to debug code that I have ever seen. Things that would take me minutes to debug in a normal setup can take hours or days. Projects like LocalStack aim to improve this a little bit but it's completely counter to the ethos of many "cloud-first" developers.

l30n4da5 4y ago

> Moving everything into hard to debug http calls has been a disastrous productivity sink. I'll admit for the vast majority of web apps out there, this is not needed, but there is definitely a scalability concern if your entire stack is a single ruby on rails mvc application.

sparker72678 4y ago
This is the misconception that will just never die. I've worked on multiple products with 1 million+ users running on stock Rails MVC backends. Everything scales just fine. Until you hit a DB hardware limit you can just keep adding more web instances behind your load balancer. And DB Hardware limits these days are astronomical. If you're actually hitting the limit of scaling our web backends horizontally and you don't have the money to deal with the problem, you might need to take a hard look at your product. And I'm confident this is true for whatever your backend is: Django, Rails, Laravel, whatever.