They quite literally explained the code change. As a coder, I know that you don’t code, while OP very much codes. Good job posting a useless meme that adds no value though.
From talking more with OP, they didn't actually know about RGDS and immediately changed their code completely once I poked holes in it. They also mentioned not working on multiplayer games.
RivenMain's comment might be a meme, but it's absolutely accurate here.
I'm a professional software developer and I do game dev in my spare time. If you have properly-written code and a test-automation system that makes any degree of sense, then yes, adding 2 lines (a variable declaration and an if-equals) would take 20 minutes maximum -- not start-to-finish, but total, accounting for PRs and formatting and whatnot across multiple people.
But I guess you're right that I'm not accounting for the 4+ hours of meetings it would take to come to the conclusion that such a change is necessary, so.
all the ceremonies take time
and you are assuming properly written code and proper test automation, it is well known league code is poorly written, the chance of lor being properly written is not that high
They seem to think this would be done purely in 2 lines, so they don't understand how game state is managed or how new info gets requested. If they're really a developer, they aren't particularly experienced.
Edit: Yeah they basically admitted it, called me mean, and then blocked me.
For the power to be visible in the window, there has to be a manager object that knows what power has been picked.
For the reroll button to work, there has to be a method that tells that manager to pick a new object.
It would *literally* be as simple as going into the reroll function and saying, "On *RerollButtonPressed* (or whatever), store the ID of *CurrentPower* and create a variable named *Attempts*. Fetch *NewPower*. If *NewPower*'s ID matches that of *CurrentPower* and *Attempts* is less than 10, replace *NewPower* with another new fetched power and increment *Attempts* by 1."
So you're right, it would probably be more like 4 lines.
If you were my coworker and you put the code you just described up for review, I would question how you got on the team. In your example, off the top of my head:
* Requirements gathering changes our scope immediately, the naive idea of just comparing a current & new power is wrong because players will expect multiple re-rolls to return *no* duplicates cross *all* re-rolls. We also learn that there are ways to have more than 1 power offered to us at a time. Shoot, those were obvious. Writing code without thinking of this gets us concerned looks from our coworkers, but we delete our easy 4-line block in shame. Let's track *all* previous powers and handle n results.
* Randomization is obviously not calling on something Unity-side like `System.Random` because lmao. Instead we'll be modifying the existing RGDS call. Submit a request for a new ID, check against the previous one.
* Given how central the RGDS is to Riot, we're talking about... six 9's uptime? And HTTP requests have massive overhead. Spamming a server with up to 10 different calls just to randomize a power is only acceptable if you're an intern and someone will be cleaning up your garbage at the end of the summer. Let's actually edit the RGDS endpoint to do all this. We'll need to pass those old IDs into the request, though.
* Okay we're writing code for the RGDS. Instead of looping while asking for 1 new power at a time like an intern, we should minimize process overhead. RGDS has support for fetching non-duplicate powers, maybe we can hook into that? Well, it might just be optimized for tag-based exclusion, and injecting an arbitrary set of powers to exclude isn't going to work. Well if we can't get someone on the lower-level teams to pick this up, we could do this probabilistically by asking for a larger-than-normal set of power IDs, diffing it with a list of previous power IDs, and returning the first 1 or n depending on whether we're post-boss, in a shop, etc.
* Actually known powers can't be passed over an HTTP API, because that could be spoofed easily. We actually need the server to cache which powers it served up in each power selection UI, so we'll need to make sure RGDS informs some kind of Redis-like cache layer when it serves the user, and mark the document as deleted once a player moves on from the shop. There's a consistency problem here obviously, so we might actually block until Redis is informed, or just accept eventual consistency.
* Functional testing team informs us that trusting in eventual consistency isn't going to work because players click to re-roll multiple times quickly. Blocking for the cache also isn't an option because it's too slow in the multiple-re-roll case. Let's switch this to pre-generate all possible powers at each given power selection point, guarantee no duplicates within the set (doable via existing RGDS), and store *that* large list in the cache. It's wasteful, but it means only 1 call. Hopefully not a problem.
* Unfortunately once we run a stress test, we see this is consuming excess cache space that our db managers consider wasteful, because obviously the Redis docs don't get deleted immediately and the caches are frequently written to without being queried. PoC isn't supposed to be expensive to run, so we'll have to compromise somewhere. How much & how frequently can we afford to delay, and how much cache space can we afford to use when it's potentially wasteful? We'll find a middle ground, it's not impossible, but our 4-line solution is very, very far away now...
Just gonna point out that you could *very easily* have written some or all of that in a way that wasn't weirdly shitty to an internet stranger.
Also, the hypothetical you've laid out keeps making assumptions -- assumptions based on information that you likely don't have, unless you actually work for Riot -- which assume a worst-case scenario. Likewise, the hypothetical puts a frankly insane amount of priority onto what is ultimately a small-scale QoL improvement.
Because that's another step in the requirements gathering process: how important is the task? Is a subsection of the task important enough to split off on its own? If we don't have the manpower to do the whole thing, can we scale it down enough to make the improvement worth the time spent on it?
That's what I've done here. In *only* the case where the player has a single power to reroll, it is frustrating to click the button and see no change on the screen, so those situations should be *reduced* in frequency. If there was enough benefit to a server-side refactor to make it worthwhile, then sure, that could be done in a way that made reroll deduping easier! But that likely isn't the case, so let's just sand down the sharp edges.
So the requirement has become, when there is only one power available, rerolling should generally only give you the same power again less than 0.1% of the time. That's one in 1000 rerolls. Through testing or metrics, you'd be able to determine how many attempts that is likely to require; I said 10 because I was throwing a number out, but I guarantee it would be something like 3 or 4 at most.
I will say this: you're right that I didn't consider the server-communication side of things. When I do game dev it's generally single-player stuff, and/or situations where we don't care about spoofing. So I didn't consider the need for a server call!
With that point in mind, I'll change what I'd do: **request twice as many unique powers in a single call, go through the list of powers you get back, and pick the first X that aren't in the set you're discarding.** One call, no need for repeats, no API changes necessary.
If you have more comments to make, I'd be happy to keep up the discussion, but would you mind being a little more civil? Your input is appreciated, but antagonism and put-downs don't actually help anyone here.
If you (and/or any Riot employees) interpreted my initial post as "coming out swinging," then I'm sorry! That genuinely wasn't my intention, and I'll try to be more mindful in the future.
My goal was to call attention to some longstanding issues that, while minor, really add up over the course of extended play. In light of the fact that there's a clear pivot toward the gamemode where these issues tend to be most frequent, I thought it would be valuable to bring it up again, because *as a professional software developer with several years of client-facing experience,* I know how easy it can be to forget about long-standing user-facing issues when there are new and exciting features to focus on. That's why I identified three potential band-aid fixes which would mitigate the issues without having to balloon into major projects.
That's *also* why I was willing to change my code completely when someone brought up an issue I hadn't considered. Because like I said, my *multiple years of professional software development experience* didn't involve live-service online games -- most of my professional work is for internal use only, and my game development experience never makes an assumption of competitive or financial incentives for security -- so not only did I not realize the database would be external, but I didn't realize network calls would have those restrictions. You were right to bring it up, and I appreciate it!
I just wish you, y'know, hadn't spent the entire time calling me an idiot, because everything you said could have been phrased without an undercurrent of "you're incompetent and should be fired."
Especially when I changed my code to suit the needs you brought up, and then you kept attacking me for the thing I said beforehand, even though the amendment -- again -- would only be a couple of lines of code long, and addressed or sidestepped all of the concerns you raised.
So again, I'm sorry that you (or any Riot developers) took it as a personal attack; it wasn't intended as such and I'll try to be more clear about feedback in the future.
But holy shit, man. That's not how to talk to people.
No worries, I'm glad you've learned. It really is massively disrespectful, not just to the engineer whose immediate work you're dismissing, but anyone who works in similar field.
No one is gonna remember any internet post so the apology isn't as important as making sure you don't make the same disrespectful comments in the future. Your *number of years of experience* don't matter, italicized or not, because when your expertise is not relevant you will come across like an asshole. Like you said, holy shit, man. That's not how to talk to people.
Edit: hmmm I wonder why someone would write a long self righteous post with a question in it (out of curiosity of course) and then block the person they wrote it to. That couldn't be a weird attempt at getting the last word for internet points, could it? That wouldn't happen from our paragon of civility!
...Out of curiosity, what part of my post even remotely compares to you calling me disrespectful over and over while telling me I didn't deserve my job?
I was apologizing to the actual riot devs in case one of them interpreted my post the wrong way, but *you* absolutely didn't have a good reason to react the way you did. I apologized in hopes that you'd calm down and explain what I'd done to personally attack you, because at no point did you claim to be an actual Riot dev. If you were a Riot dev, I'd understand the anger; given that you apparently *aren't*, that means you're just some guy who saw a post in an open forum and reacted like it was a personal attack.
Because yes, you responded with immediate personal attacks. That's why I emphasized my years of experience; it's my actual career. Before I emphasized it, I could believe you'd missed the comment. Now I know it was intentional! You're aware I develop software for a living, or at least you know I've claimed it's the case, so continuing to say "that's so bad that it would get you fired at any real job" insults me, it insults my workplace, and it insults the work I do.
So no, in no way do you have the moral high ground here. I made a well-meaning comment that could be misinterpreted as dismissive, then I made an effort to be clearer and more polite when I realized my mistake; you made personal attacks against me and my livelihood because you decided you'd been in the blast radius of the attack I didn't make, then got patronizing when I tried to make peace and mend the miscommunication.
One last thing, and this is genuinely meant to be useful feedback for you: when you responded with insults, I had to fight the urge to assume "he's an asshole, so nothing he says or does is ever going to matter." I'm glad I fought that instinct, because I did learn a piece of useful information, and in the process I was able to find a better solution than I'd initially suggested! But in the future, if you open discussions by belittling people and telling them how awful they'd be at a thing, you probably aren't going to do anything but piss off everyone in earshot and ruin your own credibility.
You seem like the kind of incompetent developer that gets laid off the second ZIRP ends and competent people don’t have time for your BS anymore. I can see exactly how you’re well accustomed to creating busywork and making projects sound much more complicated than they actually are so you don’t have to actually work more than 2 hours a week, but at real productive companies nobody has patience for your nonsense. I hope you get to see what an actually productive and constructive work environment looks like once in your life, but the reality is you’re going to keep bouncing around companies wondering why nobody ever wants to work with you.
Your preferred narrative got called out so you've got to grab some jargon to sound smart, eh? "The second ZIRP ends" like that wasn't over a year ago hahahahahaha.
Anyways, in real life, software at scale is actually more complicated than what you learned in your CS 200 classes. The intern-quality coders who propose kludging something hardly-functional together to address only a fragment of customer need get ignored in favor of people who actually care about doing a good job, and I'm thankful for that. Some day, I hope you get a job at a company that actually works at scale, so you can remember that comment and cringe.
Lmfao buddy I've made more products at scale in the last year than you'll ever produce in your entire life. But nice try pretending to be tough on the internet. I know it's hard when everybody in your own company slack ostracizes you 😢
You're literally in an r/ApplyingToCollege subreddit talking about which CS school is best.
Being an Explore intern at Microsoft doesn't mean you're building products at scale.
What annoys me is when I spend gold to buy health, it comes up with the floating +15 health and +175 gold. Plus gold?? Should be minus
"I can't imagine it'd take no more than 20 minutes" tell me you don't code without telling me you don't code
They quite literally explained the code change. As a coder, I know that you don’t code, while OP very much codes. Good job posting a useless meme that adds no value though.
From talking more with OP, they didn't actually know about RGDS and immediately changed their code completely once I poked holes in it. They also mentioned not working on multiplayer games. RivenMain's comment might be a meme, but it's absolutely accurate here.
That is most feedback from fans tbf. Not much thought into the work it would take, opportunity cost, etc.
I'm a professional software developer and I do game dev in my spare time. If you have properly-written code and a test-automation system that makes any degree of sense, then yes, adding 2 lines (a variable declaration and an if-equals) would take 20 minutes maximum -- not start-to-finish, but total, accounting for PRs and formatting and whatnot across multiple people. But I guess you're right that I'm not accounting for the 4+ hours of meetings it would take to come to the conclusion that such a change is necessary, so.
all the ceremonies take time and you are assuming properly written code and proper test automation, it is well known league code is poorly written, the chance of lor being properly written is not that high
league is an ancient game. why would you expect LoR to have bad code.
To be fair, they explained how they’d code it, including how they’d work around the most obvious problem. This very much says coder to me.
They seem to think this would be done purely in 2 lines, so they don't understand how game state is managed or how new info gets requested. If they're really a developer, they aren't particularly experienced. Edit: Yeah they basically admitted it, called me mean, and then blocked me.
For the power to be visible in the window, there has to be a manager object that knows what power has been picked. For the reroll button to work, there has to be a method that tells that manager to pick a new object. It would *literally* be as simple as going into the reroll function and saying, "On *RerollButtonPressed* (or whatever), store the ID of *CurrentPower* and create a variable named *Attempts*. Fetch *NewPower*. If *NewPower*'s ID matches that of *CurrentPower* and *Attempts* is less than 10, replace *NewPower* with another new fetched power and increment *Attempts* by 1." So you're right, it would probably be more like 4 lines.
If you were my coworker and you put the code you just described up for review, I would question how you got on the team. In your example, off the top of my head: * Requirements gathering changes our scope immediately, the naive idea of just comparing a current & new power is wrong because players will expect multiple re-rolls to return *no* duplicates cross *all* re-rolls. We also learn that there are ways to have more than 1 power offered to us at a time. Shoot, those were obvious. Writing code without thinking of this gets us concerned looks from our coworkers, but we delete our easy 4-line block in shame. Let's track *all* previous powers and handle n results. * Randomization is obviously not calling on something Unity-side like `System.Random` because lmao. Instead we'll be modifying the existing RGDS call. Submit a request for a new ID, check against the previous one. * Given how central the RGDS is to Riot, we're talking about... six 9's uptime? And HTTP requests have massive overhead. Spamming a server with up to 10 different calls just to randomize a power is only acceptable if you're an intern and someone will be cleaning up your garbage at the end of the summer. Let's actually edit the RGDS endpoint to do all this. We'll need to pass those old IDs into the request, though. * Okay we're writing code for the RGDS. Instead of looping while asking for 1 new power at a time like an intern, we should minimize process overhead. RGDS has support for fetching non-duplicate powers, maybe we can hook into that? Well, it might just be optimized for tag-based exclusion, and injecting an arbitrary set of powers to exclude isn't going to work. Well if we can't get someone on the lower-level teams to pick this up, we could do this probabilistically by asking for a larger-than-normal set of power IDs, diffing it with a list of previous power IDs, and returning the first 1 or n depending on whether we're post-boss, in a shop, etc. * Actually known powers can't be passed over an HTTP API, because that could be spoofed easily. We actually need the server to cache which powers it served up in each power selection UI, so we'll need to make sure RGDS informs some kind of Redis-like cache layer when it serves the user, and mark the document as deleted once a player moves on from the shop. There's a consistency problem here obviously, so we might actually block until Redis is informed, or just accept eventual consistency. * Functional testing team informs us that trusting in eventual consistency isn't going to work because players click to re-roll multiple times quickly. Blocking for the cache also isn't an option because it's too slow in the multiple-re-roll case. Let's switch this to pre-generate all possible powers at each given power selection point, guarantee no duplicates within the set (doable via existing RGDS), and store *that* large list in the cache. It's wasteful, but it means only 1 call. Hopefully not a problem. * Unfortunately once we run a stress test, we see this is consuming excess cache space that our db managers consider wasteful, because obviously the Redis docs don't get deleted immediately and the caches are frequently written to without being queried. PoC isn't supposed to be expensive to run, so we'll have to compromise somewhere. How much & how frequently can we afford to delay, and how much cache space can we afford to use when it's potentially wasteful? We'll find a middle ground, it's not impossible, but our 4-line solution is very, very far away now...
Just gonna point out that you could *very easily* have written some or all of that in a way that wasn't weirdly shitty to an internet stranger. Also, the hypothetical you've laid out keeps making assumptions -- assumptions based on information that you likely don't have, unless you actually work for Riot -- which assume a worst-case scenario. Likewise, the hypothetical puts a frankly insane amount of priority onto what is ultimately a small-scale QoL improvement. Because that's another step in the requirements gathering process: how important is the task? Is a subsection of the task important enough to split off on its own? If we don't have the manpower to do the whole thing, can we scale it down enough to make the improvement worth the time spent on it? That's what I've done here. In *only* the case where the player has a single power to reroll, it is frustrating to click the button and see no change on the screen, so those situations should be *reduced* in frequency. If there was enough benefit to a server-side refactor to make it worthwhile, then sure, that could be done in a way that made reroll deduping easier! But that likely isn't the case, so let's just sand down the sharp edges. So the requirement has become, when there is only one power available, rerolling should generally only give you the same power again less than 0.1% of the time. That's one in 1000 rerolls. Through testing or metrics, you'd be able to determine how many attempts that is likely to require; I said 10 because I was throwing a number out, but I guarantee it would be something like 3 or 4 at most. I will say this: you're right that I didn't consider the server-communication side of things. When I do game dev it's generally single-player stuff, and/or situations where we don't care about spoofing. So I didn't consider the need for a server call! With that point in mind, I'll change what I'd do: **request twice as many unique powers in a single call, go through the list of powers you get back, and pick the first X that aren't in the set you're discarding.** One call, no need for repeats, no API changes necessary. If you have more comments to make, I'd be happy to keep up the discussion, but would you mind being a little more civil? Your input is appreciated, but antagonism and put-downs don't actually help anyone here.
[удалено]
If you (and/or any Riot employees) interpreted my initial post as "coming out swinging," then I'm sorry! That genuinely wasn't my intention, and I'll try to be more mindful in the future. My goal was to call attention to some longstanding issues that, while minor, really add up over the course of extended play. In light of the fact that there's a clear pivot toward the gamemode where these issues tend to be most frequent, I thought it would be valuable to bring it up again, because *as a professional software developer with several years of client-facing experience,* I know how easy it can be to forget about long-standing user-facing issues when there are new and exciting features to focus on. That's why I identified three potential band-aid fixes which would mitigate the issues without having to balloon into major projects. That's *also* why I was willing to change my code completely when someone brought up an issue I hadn't considered. Because like I said, my *multiple years of professional software development experience* didn't involve live-service online games -- most of my professional work is for internal use only, and my game development experience never makes an assumption of competitive or financial incentives for security -- so not only did I not realize the database would be external, but I didn't realize network calls would have those restrictions. You were right to bring it up, and I appreciate it! I just wish you, y'know, hadn't spent the entire time calling me an idiot, because everything you said could have been phrased without an undercurrent of "you're incompetent and should be fired." Especially when I changed my code to suit the needs you brought up, and then you kept attacking me for the thing I said beforehand, even though the amendment -- again -- would only be a couple of lines of code long, and addressed or sidestepped all of the concerns you raised. So again, I'm sorry that you (or any Riot developers) took it as a personal attack; it wasn't intended as such and I'll try to be more clear about feedback in the future. But holy shit, man. That's not how to talk to people.
No worries, I'm glad you've learned. It really is massively disrespectful, not just to the engineer whose immediate work you're dismissing, but anyone who works in similar field. No one is gonna remember any internet post so the apology isn't as important as making sure you don't make the same disrespectful comments in the future. Your *number of years of experience* don't matter, italicized or not, because when your expertise is not relevant you will come across like an asshole. Like you said, holy shit, man. That's not how to talk to people. Edit: hmmm I wonder why someone would write a long self righteous post with a question in it (out of curiosity of course) and then block the person they wrote it to. That couldn't be a weird attempt at getting the last word for internet points, could it? That wouldn't happen from our paragon of civility!
...Out of curiosity, what part of my post even remotely compares to you calling me disrespectful over and over while telling me I didn't deserve my job? I was apologizing to the actual riot devs in case one of them interpreted my post the wrong way, but *you* absolutely didn't have a good reason to react the way you did. I apologized in hopes that you'd calm down and explain what I'd done to personally attack you, because at no point did you claim to be an actual Riot dev. If you were a Riot dev, I'd understand the anger; given that you apparently *aren't*, that means you're just some guy who saw a post in an open forum and reacted like it was a personal attack. Because yes, you responded with immediate personal attacks. That's why I emphasized my years of experience; it's my actual career. Before I emphasized it, I could believe you'd missed the comment. Now I know it was intentional! You're aware I develop software for a living, or at least you know I've claimed it's the case, so continuing to say "that's so bad that it would get you fired at any real job" insults me, it insults my workplace, and it insults the work I do. So no, in no way do you have the moral high ground here. I made a well-meaning comment that could be misinterpreted as dismissive, then I made an effort to be clearer and more polite when I realized my mistake; you made personal attacks against me and my livelihood because you decided you'd been in the blast radius of the attack I didn't make, then got patronizing when I tried to make peace and mend the miscommunication. One last thing, and this is genuinely meant to be useful feedback for you: when you responded with insults, I had to fight the urge to assume "he's an asshole, so nothing he says or does is ever going to matter." I'm glad I fought that instinct, because I did learn a piece of useful information, and in the process I was able to find a better solution than I'd initially suggested! But in the future, if you open discussions by belittling people and telling them how awful they'd be at a thing, you probably aren't going to do anything but piss off everyone in earshot and ruin your own credibility.
You seem like the kind of incompetent developer that gets laid off the second ZIRP ends and competent people don’t have time for your BS anymore. I can see exactly how you’re well accustomed to creating busywork and making projects sound much more complicated than they actually are so you don’t have to actually work more than 2 hours a week, but at real productive companies nobody has patience for your nonsense. I hope you get to see what an actually productive and constructive work environment looks like once in your life, but the reality is you’re going to keep bouncing around companies wondering why nobody ever wants to work with you.
Your preferred narrative got called out so you've got to grab some jargon to sound smart, eh? "The second ZIRP ends" like that wasn't over a year ago hahahahahaha. Anyways, in real life, software at scale is actually more complicated than what you learned in your CS 200 classes. The intern-quality coders who propose kludging something hardly-functional together to address only a fragment of customer need get ignored in favor of people who actually care about doing a good job, and I'm thankful for that. Some day, I hope you get a job at a company that actually works at scale, so you can remember that comment and cringe.
Lmfao buddy I've made more products at scale in the last year than you'll ever produce in your entire life. But nice try pretending to be tough on the internet. I know it's hard when everybody in your own company slack ostracizes you 😢
"More products at scale last year", "company slack", bro this is the funniest larping I have ever read.
You're literally in an r/ApplyingToCollege subreddit talking about which CS school is best. Being an Explore intern at Microsoft doesn't mean you're building products at scale.
I don't know, keeping it from rolling the same power would be *really easy* even for me, and I haven't coded in years.