Another take: Dev 1: Hey, I think we can improve the load time by fixing X, Y, and Z. Dev 2: that's neat, create a ticket so we can keep track of that. Product 1: hey, what's this ticket about? Dev 1: oh, that's to speed up the load time. It's a quick fix. Product 1: was that in the requirements? Dev 1: No, but it will be a huge improvement. Product 1: ok, I'll mark it as Tech debt, and put it in the back log. ~~ Man…
That's why you stop asking permission to make quick fixes and just submit the PR. Obviously there is a balance here but if you can't "steal" a few hours in a week from the product driven roadmap to do so then there is something wrong in the engineering culture.
I cut GTA Online loading times (2021)
181–190 of 221 posts
Re: I cut GTA Online loading times (2021)
#182Also a good reminder that the slow thing may not be what you think and if you aren’t profiling you don’t really know what’s going on.
And an even better reminder that typical “metrics” trying to assess developer value can be pretty meaningless. This is the kind of code change that would drastically improve everything but show up as a blip on some of the pathetic measurements out there, e.g. hardly any lines of code or whatever.
Re: I cut GTA Online loading times (2021)
#183Earlier quoted context omitted.
Do any orgs explicitly ask the engineers themselves decide how to allocate a certain percentage of story points in a given sprint? Product people are great for selecting which features to build out and which bugs to address, but are poorly equipped to decide how to prioritize things like: performance optimizations, bugfixes that haven't (yet) been reported by the end users, code refactoring, paying down tech debt, mo…
My first job worked like that. We explicitly had a 25% stream of technical improvements. It worked pretty well.
Re: I cut GTA Online loading times (2021)
#184Earlier quoted context omitted.
That's why you stop asking permission to make quick fixes and just submit the PR. Obviously there is a balance here but if you can't "steal" a few hours in a week from the product driven roadmap to do so then there is something wrong in the engineering culture.
Absolutely. If something is oddly slow, I run the profiler to see what's going on. If the profiler shows me something boneheaded like this that is a big win to fix, I fix it. Obviously I make sure the tests still pass, but then I check it in. If someone is going to give me shit for improving the product, that is not somewhere I want to work.
Re: I cut GTA Online loading times (2021)
#185Earlier quoted context omitted.
Not to mention, unless they have a really clever system to do hot code reloading, EVERY SINGLE DEVELOPER AND TESTER would have been plagued by these load times. I wonder if the watercooler rooms at Rockstar are exceptionally furnished as a result.
Sometimes testers aren't even working with the full data set. And testers might have some seriously shit-hot hardware that is max spec too. When I was developing everyone would go buy the absolute best PCs out there at the start of every new game to make sure they lasted through dev.
Re: I cut GTA Online loading times (2021)
#186Earlier quoted context omitted.
The customer has put up with 6 minute load times, but a low framerate kills sales quickly (unless you're Star Citizen).
And kills reviews. Most reviewers won't freak about the load time, but the framerate they will.
Re: I cut GTA Online loading times (2021)
#187Another take: Dev 1: Hey, I think we can improve the load time by fixing X, Y, and Z. Dev 2: that's neat, create a ticket so we can keep track of that. Product 1: hey, what's this ticket about? Dev 1: oh, that's to speed up the load time. It's a quick fix. Product 1: was that in the requirements? Dev 1: No, but it will be a huge improvement. Product 1: ok, I'll mark it as Tech debt, and put it in the back log. ~~ Man…
That's why you stop asking permission to make quick fixes and just submit the PR. Obviously there is a balance here but if you can't "steal" a few hours in a week from the product driven roadmap to do so then there is something wrong in the engineering culture.
Re: I cut GTA Online loading times (2021)
#188Earlier quoted context omitted.
Absolutely. If something is oddly slow, I run the profiler to see what's going on. If the profiler shows me something boneheaded like this that is a big win to fix, I fix it. Obviously I make sure the tests still pass, but then I check it in. If someone is going to give me shit for improving the product, that is not somewhere I want to work.
The boy scout "leave it better than you found it" mantra has always served me well. Hell, sometimes that small fix can lead you down a rabbit hole that uncovers fixes to larger problems that have been plaguing an app for an eternity.
Re: I cut GTA Online loading times (2021)
#189Earlier quoted context omitted.
You're probably wrong. I remember e-commerces trying to quantify how many millions of dollars they would lose when clicking would take too much time on their websites. EDIT: things like https://www.fastcompany.com/1825005/how-one-second-could-cos... > Amazon’s calculated that a page load slowdown of just one second could cost it $1.6 billion in sales each year. Google has calculated that by slowing its search results…
That's ecommerce. This is a video game and a unique one at that, so there are other factors at play. I don't think many people go "game took forever to load, guess I'll play for less time then." There could even be a bullwhip effect, a long load time might make you want to stay playing for a longer period of time.
Re: I cut GTA Online loading times (2021)
#190Another take: Dev 1: Hey, I think we can improve the load time by fixing X, Y, and Z. Dev 2: that's neat, create a ticket so we can keep track of that. Product 1: hey, what's this ticket about? Dev 1: oh, that's to speed up the load time. It's a quick fix. Product 1: was that in the requirements? Dev 1: No, but it will be a huge improvement. Product 1: ok, I'll mark it as Tech debt, and put it in the back log. ~~ Man…
That's why you stop asking permission to make quick fixes and just submit the PR. Obviously there is a balance here but if you can't "steal" a few hours in a week from the product driven roadmap to do so then there is something wrong in the engineering culture.