Diverse skills can be super important. Even if you're talking about computer graphics in a really curmudgeonly field.
I'm in GIS. (geospatial information systems) Turns out knowing how to define a camera using a matrix and intersecting a ray with a mesh of triangles is pretty useful. And it turns out that if you don't know how to do these things and just sit down and start cowboy coding the solution you're gonna come up with is going to need to be rewritten by the person they hire when you leave.
There are a lot of things I run into in my job where I genuinely don't know what the right algorithm is, compared to the number of times I've said "I recognize this thing" and brush up on the literature and implement some variation on it as applicable to my particular usecase. I'm kinda curious as to how much of the stuff I've written has someone come across it later and been like, "wtf is this shit, you just use <so and so's (probably Djikstra's)> algorithm".
For me the most useful skill has been to recognise when I'm doing something that's O(n^2) or worse, especially if it involves doing anything besides just math (e.g. database queries, file reads, web requests, etc) If something is O(n^2) or worse it's a good sign I should probably google around for a better algorithm.
Thankfully python has a rich set of built in datastructures, using a dict (or a hash map in other languages) turns a lot of O(n) problems into O(1) problems. The bisect module turns O(n) problems into O(n log n) problems. I'm always keeping my eye out for more of these big-o-reducers.
That said, in production software it hardly ever matters these days as long as you're not doing anything exceedingly daft. Fast enough is fast enough.
I'm in GIS. (geospatial information systems) Turns out knowing how to define a camera using a matrix and intersecting a ray with a mesh of triangles is pretty useful. And it turns out that if you don't know how to do these things and just sit down and start cowboy coding the solution you're gonna come up with is going to need to be rewritten by the person they hire when you leave.
There are a lot of things I run into in my job where I genuinely don't know what the right algorithm is, compared to the number of times I've said "I recognize this thing" and brush up on the literature and implement some variation on it as applicable to my particular usecase. I'm kinda curious as to how much of the stuff I've written has someone come across it later and been like, "wtf is this shit, you just use <so and so's (probably Djikstra's)> algorithm".