I worked with the man for years in the Xbox Advanced Technology Group. Amazing individual. When he left the team, I conducted my own exit interview so I could learn from him, and walked away with pages and pages of insights on growing my own career and becoming a subject matter expert.
He was on my interview loop at ATG, and I recount it as my favorite interview of all time. He pointed to a circuit diagram poster, and said to me "You have to write a game for that, what design considerations should you be aware of?"
A bit out of my league, but I identified the important aspects (multicore/hyperthreaded design, small L0/L1 cache and impacts to mispedictions, etc.) and spoke to what I could and where my uncertainties lay. Afterwards he gave up the rest of the time to let me ask questions about the team.
One XFest he stood on stage giving a Powerpoint presentation on debugging and multithreaded concerns. An animation was slow, and he broke into it and started debugging Powperpoint live to demonstrate some of his techniques. A legend.
A huge loss to Microsoft when we stepped away. I did and do hope him the best!
Can you describe some of the insights you learned from the exit interview -- about growing your career and becoming a subject matter expert? I'm new to the field and I feel like that'd be immensely valuable to me and many others.
Sure! It's been a decade, but the biggest thing that stuck out was to pick something that needs an SME. Fill a gap on the team, even if it's something you may not have a huge interest in. Find the interest in it, and _own it_.
But most importantly, give talks and brownbags about the technology. Understand that there's going to be someone in the room that knows more than you... but they aren't giving the talk and helping everyone else, you are. They will chime in, and that's OK. You are the one putting yourself out there educating yourself and others. This helped me so much when I gave talks at GDC... even if I'm helping ONE person, it makes the event worth it (and the talk serves as my unique perspective / take on the industry).
Pour over source materials. Bruce read the 600+ page CPU documentation front-to-back, twice over. He said the second time, he gleaned so much more insight.
The engineers didn't realize just how much knowledge they were trying to distill, so you might read a comment that says "Of course, the second parameter determines XYZ." The first read-through, you might gloss over that. The second read-through, you realize the instruction they're documenting is doing double-duty elsewhere, and the comment is an important indicator of how that interaction plays out on the die.
>One XFest he stood on stage giving a Powerpoint presentation on debugging and multithreaded concerns. An animation was slow, and he broke into it and started debugging Powperpoint live to demonstrate some of his techniques. A legend.
Is there a video of this somewhere? Sounds amazing.
To be clear, the profiling of Powerpoint in the middle of the presentation was a stunt, planned in advance. I just didn't tell anybody I was going to do that.
At that point I was an ex-Microsoft person giving a talk at a Microsoft conference using Microsoft tools to profile Microsoft's presentation software. It may have been a cheeky thing to do, but it was so much fun.
We were the firefighters when a game studio's experts couldn't figure out what was going wrong. They may provide a code snippet, or in rare cases the full game, and we could debug with the console's OS/driver source code. We even had access to the processor layouts for figuring out hardware bugs. We'd get copies of the Red Disc and Green Disc masters used for duplication, before the game was published (helped figured out a few 0-day patch bugs that way).
The other half of the job was proactively figuring out what problems studios would run into with new APIs and new SDKs. How would they want to use them together, and the challenges that posed.
Finally, we were the developer representatives, advocating on their behalf as the platform progressed.
Was an amazing job. I only left because I just couldn't pass up my dream job (reworking the telemetry/stats pipeline for Halo 5, and getting to play with TB of data).
He was on my interview loop at ATG, and I recount it as my favorite interview of all time. He pointed to a circuit diagram poster, and said to me "You have to write a game for that, what design considerations should you be aware of?"
It looked something like this (can't find the actual poster, it's been a decade): https://qph.fs.quoracdn.net/main-qimg-9cdbc7bf35ef8126755175...
A bit out of my league, but I identified the important aspects (multicore/hyperthreaded design, small L0/L1 cache and impacts to mispedictions, etc.) and spoke to what I could and where my uncertainties lay. Afterwards he gave up the rest of the time to let me ask questions about the team.
One XFest he stood on stage giving a Powerpoint presentation on debugging and multithreaded concerns. An animation was slow, and he broke into it and started debugging Powperpoint live to demonstrate some of his techniques. A legend.
A huge loss to Microsoft when we stepped away. I did and do hope him the best!