RandoHolmes

Yeah... I quickly revised my opinion after continuing through the comments of this thread.

Apparently there ARE people who are that angry? It doesn't really make sense to me.

I saw one poster compare it to smokers who get to take quick smoke breaks. I don't have a habit that forces me to take breaks every 30 minutes to an hour or I go into withdrawal, doesn't make me smell like a smoker, and doesn't inherently put me at risk of cancer. Isn't that in itself a reward for not smoking? Instead you have to get pissed at someone who smokes? Do you REALLY want to be out there inhaling that smoke with the other smokers?

It just makes no sense to me, but I've also never viewed working hours as a zero-sum game.

His explanation is that's what google cloud defaulted too, although I have a really hard time believing that.

I'm more inclined to believe he googled and blindly followed an old guide with an old ppa than I am to believe that google cloud by default installed an EOL PHP server.

I'm pretty sure he was a node guy who found himself in the PHP world.

I just pay a CPA. It's worth the cost, they're legally liable if they make a mistake, and they'll keep your records for a minimum of 5 years (you should also be keeping your own records).

Plus, if something wonky does happen, they know what the hell to do.

> Had we invested in more sustainable development earlier, I think we would have been able to move faster to take advantage of new opportunities, diversify our revenue streams earlier (adding to them now is hamstrung in large part because of tech debt), and head off competitors faster.

While that's probably true, it's a difficult balance to know when exactly you should start moving back towards the better development practices. Too soon and you die, too late and you can no longer move because you're too inefficient.

> One reason for this was how heavily we prioritized first mover advantage. We pushed extremely hard to get into new markets, and while strategically this worked out extremely well for us, it meant that later development was hamstrung by earlier decisions.

I've seen so many developers over the years who view having to rewrite that module because it can't scale well enough anymore as a failure, but I call it a success. Software is meant to be tumultuous, things SHOULD be getting replaced.

In another post in this thread I mentioned that software systems are like children in that they have phases. Assuming that your company and software team is dedicated to fixing those issues (slowly, beside new features), then I think you're probably in a healthy spot despite the pain.

An observation is that business interests must ALWAYS trump technical interests when those business interests are critical. No business = no technical. But at some point when the company becomes stable that balance has to start shifting back towards the technical or the company itself becomes ridiculously inefficient.

I think the problem is that the leaders in the company (technical or otherwise) didn't recognize that software systems are like children: They have phases.

The ship it constantly is probably ok when you're small, but at some point you need to become more mature than that, both as an organization, and as an approach to the software itself.

The day old.reddit.com goes away is the same day I completely stop using reddit. The main interface is actively unusable for me.

7 years isn't even close to a "huge span of time".

100% with you there.

I personally think it's a bit insane to add node.js as a dependency to a simple PHP project.

My experience is that it's just as relevant today.

I had a front-end developer come in and add node, bootstrap, and SCSS as a dependency to a very simple app. We went from having a super simple build chain to one that now needed maintenance. And part of his argument? he "thought better" in SCSS.

People have zero respect for the risk of dependencies, complicating the buildchain, or long term maintenance.

> The frontend dev using half of the React ecosystem on a static site + simple form is to blame.

I once saw a website that took a full minute to load, and it was literally a page with images, text overflowing around it, and then some download links. But the way it was built... my god, the way it was built.

That company brought in a new "CTO", and his solution was to dump the entire thing in google cloud. I shit you not, this CTO initially installed an EOL version of PHP, and when errors started happening, he started submitting PR's to revert the PHP code to be compatible with the EOL version of PHP.

Dumpster Fire.

The same thing happens when a coworker gets sick or goes on vacation.

roughly in the same boat you are, and I actually find it difficult to believe that this is anything more than an imagined problem.

I can't imagine there's that many people that don't understand children are important and children need to be taken care of. I certainly have never gotten angry at not getting the tax breaks those with more dependents get, and I can't imagine there's that many other people who do.

My opinion is that this is just another journalist trying to drum up drama for clicks.

I just mean that having a technical discussion is not an argument. There will be disagreements, but that doesn't make it an argument unless someone involved is taking things too far.

That's not an argument though, that's a discussion.

> You can also keep running Rails 3 for 20 more years if you want btw.

While I understand your point, not on a modern OS you can't. You literally can't build the tools necessary to run it on a modern OS. I know because I've had to deal with this many many times. You literally are forced to run that stack on a version of ruby that's EOL and on an OS that's EOL.

I mean yes, you CAN do that, just like you can run Windows Server 2000, but it's really really not a good idea.

Elixir compiles and runs on BEAM, which is a technology that's roughly 34 years old.

I think most elixir projects are on Phoenix, and while I can't speak too much about the speed of that project, the poster you're responding too has clearly stated they have an app that's 4 years old and running just fine so I have to believe it's not as much of an issue as you think.

going from .net framework to .net core will mostly be painless unless you're using a windows specific API (such as windowing).

If you're using ASP.Net MVC then your app should also come across to .net core fairly painlessly.

The only real challenge is going from the old webforms with its page lifecycle to the asp.net core. But depending on how the application was originally implemented, that really should just be about the frontend, not the entire app. And of course EF core has changes you'll need to deal with as well if you're using it.

It's by no means seamless, but MS did the best they could to maintain compatibility between the two, and you only do it once.

It should also be noted that .net framework is almost 20 years old. Doing something like this once in a 15 year period is a far cry from Laravel's every 6 months or RoR's 2-3 year cadence. IOW, it's not optimal that the divide between framework and core exists, but it's a far better story than Laravel, RoR, et al.

> And who's to say .net core doesn't have any breaking changes in 5 years, are they guaranteeing not to do any breaking changes at all to the framework?

ASP.Net core is literally just a set of libraries. You'll be able to run those on the modern version of .net in 10 years from now. We know this because it's what they did with asp.net. An application built on asp.net 1.0 will work on 4.8.

> OK, stability is relative.

I don't know what that means in this context. What I do know is that RoR versions go EOL roughly 2-3 years after they're released. That's not stable by any stretch of the imagination.

According to the article, less popular songs are still being streamed about as much as they were before.

I see this a lot from those who prefer IDE's.

It's not generally that people are saying it's impossible to do in an IDE, just that it's slower to do, and generally more awkward.

Just the other day on reddit I was having this "discussion" with someone, in which they claimed that because they have "find in files" in their IDE it's equivalent to vim `grep -iRl whatever`.

In reality I'm going to do what you're trying to do in a fraction of the time. IDE's have their advantages, but speed is not one of them.

Unless those companies are all in the same building, that's also distributed...

If I write an application in asp.net core it will continue functioning on the most recent version of .net core and asp.net core 5 years from now.

If I do the same thing on RoR it will not, guaranteed.

I've lost count of the number of times I've gotten a new client and had them on a web framework that was EOL, on a version of the language that was EOL, and on an OS that was EOL (because they couldn't get the EOL language/framework running on a modern OS).

Anytime you use something like RoR you're automatically taking on a higher maintenance burden because you MUST upgrade or you'll find yourself in a spot where you're trying to decide if you want to rewrite or pull it up to the newest version.

No part of that description screams stability.

None of that matters when determining whether or not they need to give specifics about something that is obviously true.

You sound like an anti-vaxxer.

Maybe you're right, but you're missing the point.

I'm a vim user so I mostly agree with you, but I'd like to point out that it's the entire OS that makes dealing with codebases easier.

It's a point that a lot of IDE users miss. I have grep and awk at my fingertips, you don't.

editing speed != typing speed, that confusion might explain why you don't understand.

> I say it all the time, but I think a lot of power vi/emacs users have not touched a modern IDE in a long time.

Watch as my eyes roll out of my head, onto the floor, and then out the door.

Why is it that you believe the only reason why a vi/emacs user could believe those environments are faster to edit in is because they don't use IDE's?

The worst part is that most vi/emacs users actually DO have experience in both environments, whereas most of the people who want to claim vi/emacs isn't any faster don't. Yet they want to present themselves as an authority.

And I'm one of the people who refuse to use vim emulators in IDE's because they're never quite right (and never integrate well with the IDE).

No, it's more about making them care more about paying you back. I don't agree with the practice, but lets not pretend that it's strictly about revenge rather than motivating the person to pay the debt.

This is why any of the "ilities" is a red flag for me. Don't tell me it isn't scalable, make it concrete. Tell me what specific numbers we're supposed to meet. Don't tell me it isn't readable, tell me specifically what the problem is.