Finding the bugs that piss people off. Yes, that is what I do.
After mucking around in TCL for several weeks (and seeing how horrid it was - at least the built-in version for these fpga development systems), I have a minimal tcl script that initializes the platform and then takes user input to change the fpga settings on the fly or read registers on the fpga for status and data connectivity.
The real automation is in python. In only my third python script ever, I have it controlling the tcl system fairly extensively. So far, it has helped find several bugs in the fpga development environment (like sudden and unexplained crashes), bugs in the fpga register behavior (why does reading the setting in one register erase all other data?), and even possibly other bugs in our pre-release development system (not to worry, this is why it is pre-release). I still need to figure out how to recover when the tcl app crashes (currently it takes the python script down with it). Easy enough to restart where it left off, but annoying.
The cool thing about this scripting (at least from the team's point of view) is how much it has helped speed up their work. Before, to change one setting (knob) in the FPGA would take as much as 20 manual operations. Spread that across 4 different knobs (each having 4-16 different settings) and 24 different data lanes, and that is a lot of manual tweaking. My script so far loops through all permutations in about an hour, reading a control register over 1000 times per setting to ensure low error rates, then listing the best combinations. Kind of like tuning a surround sound stereo for the best audio experience by tweaking the volume, bass, treble, and distortion on each individual speaker. This is still only scratching the surface of what I will be developing, but it is a start.
As to the bugs pissing people off, they aren't mad at me for finding them. It is after all what I was hired to do.
And I am very good at it.