« first day (2963 days earlier)      last day (2354 days later) » 

00:37
@DMGregory Funny how I never need that kind of thing... I'm wondering if my job is a bit dull because of that....
Nah, I've never needed it yet either.
I think the fanciest algorithm I've ever had to use in game stuff was some union-find silliness to work out how deep a lake in a voxel landscape can fill before spilling downstream.
That's a challenge :)
I recall having some "when will we ever need this" conversations about computational theory. Several years later I was in a meeting where someone pitched a 'solution' that amounted to solving the halting problem. When I pointed this out, the response was "yeah, okay, call it what you want - we just solve that & were done".
@Pikalek The point being that it's not possible to solve, right?
Correct. I haven't really had to pull fancy Knuth level algorithms out, but it has been useful to realize that I've wandered into the land of insolvability & switch to looking for some reasonable heuristic instead.
00:46
@Pikalek Yeah... I guess the whole point is: you can help identify problems and solutions if you know stuff :P
Like I-don't-remember-who said: "You don't know if you could use a known-and-implemented-in-std-algorithm to solve a problem if you don't know there are algorithms in std (and what they are)."
@AlexandreVaillancourt Agreed. Theoretically, that's one reason why experienced devs can command higher rates.
@Pikalek Yeah, provided that the dev has not been doing the same thing again and again and again.
@AlexandreVaillancourt Yes. To cherry pick the quote "...Specialization is for insects." Robert Heinlein.
I had a friend working at *a game company* who was tired to work on implementing the audio in *a very popular franchise* and asked his boss to change game after his third game in the franchise. He was not granted that wish. So he resigned.
@Pikalek I guess specializing in a field is ok, specializing in a task is not.
@AlexandreVaillancourt I think that's a fair refinement to make.
00:54
You can specialize in AI, as long as you don't always implement the same behaviours, with the same constraints and ect.
I don't recall where I read it, but I encountered something where the author was challenging the common management practice of "give work of type X to the X guy".
In the short term it gets done faster, but in the long term, it makes the team brittle since no one else knows how to X & the X has a higher risk of burns out.
I'm thinking about the scrum philosophy here, and yeah, it could be challenged.
Thinking about the bus factor.
01:45
up-to-date documentation to pass onto someone else is sort of a must at that point
02:06
@ChrisMcFarland Yeah, but who has time for documentation... :/
This python linter complains when there are more than ~15 variables in a function. That's interesting, it forces me to clean up the code!
Of course, you can cheat and put all of the variables in a dict :P
@AlexandreVaillancourt I had a horror story on a previous Ubi title about that... ;)
@DMGregory About how many variables should a script function contains?
Sadly, no. It's literally about stuffing them in a dict to get around restrictions. XD
What went wrong?
Apparently one or more programmers on a previous title had resorted to doing this to avoid unreasonably long recompilation of the main player class when they needed to add a new flag or somesuch. They just had a big map of special-case player variables.
The programmer I heard this story from was tasked with cleaning this all up after the fact when developing the sequel.
02:19
I kind of understand what's going on there... :/
They were in utter dismay that they now had to cope with ostensibly boolean flags that had three values: true, false, and not-in-the-map. And all three states were used somewhere. XD
I call this a trit :P
I think they had some more colourful language for it....
And yeah, untangling and cleaning up must have been really fun and satisfying!
Oh, lol, yeah, I guess so :)
They left the codebase in a vastly better shape than they found it, so that's definitely a nice concrete accomplishment. :)
02:24
I guess it's a good way for a new guy to understand the software on which they will work.
It's a good way to trash it too, if the peer reviews are not done correctly :P
It also makes great stories :P
03:07
Rocket League
 
1 hour later…
04:12
@AlexandreVaillancourt the bus driver
the mortician's not gonna order a code review!
but yeah, it's one of those things
too much knowledge in one person... a liability for sure
I do wish I made enough to hire a second hand, to be able to have them be a successor or something lol

« first day (2963 days earlier)      last day (2354 days later) »