Honestly, it’s a short-sighted move made with hubris by the developer’s personal ideology. Both @nutomic@lemmy.ml and @dessalines@lemmy.ml admit in the PR that it’s not a good solution, but yet they continue any way — probably because it’s an easy “solution”, despite alienating 41% of their active user base.
It’s a terrible trend in a lot of programming circles that programmers think because it is easy and it “works” that it must be correct. This can be evidenced by browsing StackOverflow and reading the accepted answers for a lot of questions (I do not have any specific examples off the top of my head).
In my 18+ years of experience, if I find an “easy” solution to a complex problem, I keep looking for the correct solution. What is “easy” now will most likely lead to more complex problems down the line. And as they say, “if you can’t find the time to fix it right the first time, where are you going to find the time to fix it again?”
Look, I get Lemmy is meant to be decentralized. Hiding away your biggest instance looks shady to outside users not in the know. The real solution is to “go door to door” to app makers and ask them to not default to any one instance of Lemmy (side note: randomizing a default server is not much better). If anything, add a link to join-lemmy where people can browse the list of ALL instances (yes, ALL of them) and let them make a genuinely-informed decision on their own. As a convenience, and API should be provided (assuming one does not already exist) so that apps can query a pageable/searchable list of existing/active instances (maybe also provide a link to their homepage too).
Hell, if it makes everyone feel warm and fuzzy, the default sorting of returned values can be weighted by percentage of active users (i.e., higher percentages get lower weights to help promote smaller instances). This would help to round out the number of signups without excluding instances.
But whatever developers do (not just Lemmy devs), do NOT overly dictate how people use your software; lest you piss your user base off.
You’re talking about something without actually clarifying what the hell you’re talking about. That’s the short sighted move? The easy “solution”? What “works”?
Because it’s not simply “distributing” the load; it’s actively hiding an instance as if it doesn’t exist. So what do they do when the next instance gets “too big” for their liking? Hide it, along side LW? And the next?
Re-read my comment — specifically the second half where I offer a potential solution that would actually distribute the load more fairly without having to hide anything.
it’s actively hiding an instance as if it doesn’t exist
For the purpose of directing new users, who tend to just pick the largest instance, sure. But if you and they are both federated, there’s no difference in the content.
So what do they do when the next instance gets “too big” for their liking? Hide it, along side LW? And the next?
Correct, because this increases the reliability of the average lemmy user’s experience as one point of failure affects fewer users.
Honestly, it’s a short-sighted move made with hubris by the developer’s personal ideology. Both @nutomic@lemmy.ml and @dessalines@lemmy.ml admit in the PR that it’s not a good solution, but yet they continue any way — probably because it’s an easy “solution”, despite alienating 41% of their active user base.
It’s a terrible trend in a lot of programming circles that programmers think because it is easy and it “works” that it must be correct. This can be evidenced by browsing StackOverflow and reading the accepted answers for a lot of questions (I do not have any specific examples off the top of my head).
In my 18+ years of experience, if I find an “easy” solution to a complex problem, I keep looking for the correct solution. What is “easy” now will most likely lead to more complex problems down the line. And as they say, “if you can’t find the time to fix it right the first time, where are you going to find the time to fix it again?”
Look, I get Lemmy is meant to be decentralized. Hiding away your biggest instance looks shady to outside users not in the know. The real solution is to “go door to door” to app makers and ask them to not default to any one instance of Lemmy (side note: randomizing a default server is not much better). If anything, add a link to join-lemmy where people can browse the list of ALL instances (yes, ALL of them) and let them make a genuinely-informed decision on their own. As a convenience, and API should be provided (assuming one does not already exist) so that apps can query a pageable/searchable list of existing/active instances (maybe also provide a link to their homepage too).
Hell, if it makes everyone feel warm and fuzzy, the default sorting of returned values can be weighted by percentage of active users (i.e., higher percentages get lower weights to help promote smaller instances). This would help to round out the number of signups without excluding instances.
But whatever developers do (not just Lemmy devs), do NOT overly dictate how people use your software; lest you piss your user base off.
/two-cents
You’re talking about something without actually clarifying what the hell you’re talking about. That’s the short sighted move? The easy “solution”? What “works”?
Why would distributing users to smaller instances alienate Lemmy.world users?
If anything, distributing the load results in a better user experience, since the last Reddit exodus was taking down .world every few hours.
Because it’s not simply “distributing” the load; it’s actively hiding an instance as if it doesn’t exist. So what do they do when the next instance gets “too big” for their liking? Hide it, along side LW? And the next?
Re-read my comment — specifically the second half where I offer a potential solution that would actually distribute the load more fairly without having to hide anything.
For the purpose of directing new users, who tend to just pick the largest instance, sure. But if you and they are both federated, there’s no difference in the content.
Correct, because this increases the reliability of the average lemmy user’s experience as one point of failure affects fewer users.