191–200 of 288 posts
"Java over Go" seems kind of weird. Go has been around for a decade and it seems like code built on 1.0 should still work, if you're not too crazy about dependencies?
Earlier quoted context omitted.
What I always say about this kind of thing is not "It's ok now because they un-did it." but "It's still not ok because they tried." If they are the kind of people who would try something, then they are still the same people and that problem did not go away. They will try something else again, and may in fact already be failing to work to my advantage right now in ways I just can't see. Once you know that, I prefer to…
So basically you must be 100% perfect all the time and are never allowed to make any mistakes. This is one of the attitudes that makes the internet so toxic IMHO.
Yes. That is exactly what I said.
Earlier quoted context omitted.
If you can have a Java backend that's more or less totally decoupled from the frontend, great. Java and it's tooling are fine, and it's easy to be productive writing in Java. However, my only experience as a frontend dev with Java backend system has been truly nightmarish, because the backend processed all the frontend assets and rendered them. If anything, this is what helped me burnout, because everyone on my team…
Yeah so the dev machine shit specs is something we fight SO HARD against in my bank. There s not many thing we can fight, but our 10 core SMT xeon with 128G of RAM for everyone in the team was a fight worth fighting. Yes, it took 2 years of them putting us on a new VM cloud systems after another before they gave up, us spamming them every say "intellij freezes", "I cant build in less than 10 minutes and the traders a…
I don't know about them right now but before I resign, I told them "have you ever calculate how much time and money wasted by just restarting our app server for local dev? you probably should be worry about that because I believe you pay us to wait for app server comes online more than we develop a feature"
Earlier quoted context omitted.
on the individual level you can make mistakes. on an organizational level allowing this kind of mistakes means they discussed it and nobody found a problem with it. its a sign of disfunction.
It's a sign of docker desperately trying to find out a way to make money and survive.
There are an infinite number of ways to make enough money to survive.
You can sell your work honestly without artificially witholding work that is already done so you can sell it a million times over, and get people to do it by artificially creating or at least artificially preserving a pain point and randsoming the salve.
That is not simply doing work and paying for that work.
If a thing is at all useful enough that anyone even wants to use it, then there are a million businesses that would love to pay you for expert installation and training and support of perfectly free software.
Ahh but that doesn't scale. You can sell your time to a few people and live very very well, but you can't sell your time to a billion people.
No one is "trying to survive" in this story. What a strange and incredible thing to even try to say.
I appreciate the contrarian point of view, and I don't want to pick on the author, but this sounds like words of wisdom from someone who doesn't have much real world experience. I worked in such a project who never upgraded once. And then Specter/Meltdown hit, and we had the mandate to patch all our systems (and the threat was very real). Welcome to a hellish mess of outdated deps that took weeks to sort out. But is…
* and have a very good test suite
"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually m…
This is why I can’t use anything too complicated. I’m just not smart enough to wrangle complex configurations and dependencies. So I keep producing Rails apps that get the job done without the bells and whistles and without much polish. I wish I could hire a config expert for half an hour and have them create the setup I want. Because I will never get my masters in webpack/rollup/postcss/stimulusjs/mystery sauce work…
This whole conversation only pertains to people who work in large companies, on salary, who both need to follow standardized procedures and have the time to spend days doing so. I always find it interesting, because it illuminates an entirely different set of priorities and a completely different universe of tools versus what an individual or 2-3-person team needs to focus on to get things running.
Timely. I was recently force upgraded to Win11. Today in fact. Last week I force-downgraded after I got an exception because it is my busy time of year. That exception was not respected and I realized fighting it weekly would be the same time investment as fixing compatibility issues. "What compatibility issues? Win11 is fine, I have had no problems." My coworkers say. Well on Day 1, 2 pretty important pieces of soft…
I upgraded to Windows 11 and the volume bar simply does not show when left clicking on the sound icon on the lower right of the task bar. No amount of things I've tried makes it work, so to change the volume I have to either use keyboard shortcuts or open the volume mixer in the control panel.
Meanwhile the defender itself keeps running and preventing me from installing latest qBittorrent because it decided that it's malicious and to overwrite I need to open Defender...
"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually m…
I appreciate the contrarian point of view, and I don't want to pick on the author, but this sounds like words of wisdom from someone who doesn't have much real world experience. I worked in such a project who never upgraded once. And then Specter/Meltdown hit, and we had the mandate to patch all our systems (and the threat was very real). Welcome to a hellish mess of outdated deps that took weeks to sort out. But is…
Did you read the part in the first paragraph where the author complains about people shutting down the idea without even giving it any discussion?
I mean you just dismissed the idea entirely and went off on a "have you tried jQuery" tangent.
> one of their biggest mistakes was not to upgrade often enough, which made each upgrade more painful.
The mistake isn't not updating frequently enough. The mistake is that the industry thinks maintaining backwards compatibility is a waste of time.
Updating more frequently doesn't magically make updating less painful, it just spreads the pain out over longer timeframes.
There is some benefit given that you won't be building on top of more and more stuff that may eventually be rug pulled by something that may already be released, but again, this isn't about update frequency, it's about a lack of respect for backward compatibility.
If everyone maintained backwards compat indefinitely we wouldn't have so many damn problems and updating would be nearly painless at whatever frequency you like.
Maintaining backwards compat isn't actually all that hard. There is two types of change. Breaking and non breaking. Most changes can be done without breakage. Want to make a breaking change to that function? Make a new function, put a 2 on the end. Problems solved. How often does leaving that old function actually cause you problems? Technically it's tech debt, but tbh it's the most benign tech debt you'll ever see.
So anyway, my point isn't that we should update frequently or not at all, it shouldn't matter. My point is that semver gives inexperienced devs a pass for lazy development practices that cost everyone instead of eating the cost themselves.
Want to release a major version change? Go for itz but understand it's a fork and not everyone needs your special new features you think is so important.
Corollary: Do hard things more often, per Martin Fowler - https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... Upgrade everything all the time and it will never be hard. You'll have full context for breaking changes, and the diff from A to B is always smaller than from A to Q, and less likely to break in strange and confusing ways.