The Git fast version control system—of course I knew of it, but hadn't ever used it. It has some great features, although its model takes a bit of getting used to. The best is being able to make branches and commits locally, without a repository (effectively a private repository). I was working on some code for the XBMC media center—scraper abstraction toward a goal of being able to use Python and other non-XML scrapers, since the XML scraper system is painful—and I was using the Subversion repository, and had a lot of changes stacked up locally which I bundled into a diff. Then I thought that I'd prefer to be able to commit these changes and move on to further modifications, but Subversion didn't do this, or at least not well; Git did. It also made it easy to split up my current changes into multiple branches and commits, and even to modify past commits (forgot to add a file… thought git commit -a would pick it up).
The Mediainfo command-line utility and library—I was using file to try to compare two different movie files' bitrate and dimensions, but one was MP4 and it only said "ISO Media, MPEG v4 system, version 1" (which really isn't bad for a utility that is supposed to identify file types and not be too concerned about content). I searched around and found Mediainfo, and found what I needed to know.
I've already mentioned symlink trees, but I found another use for them, not a new one by any means: shadow source trees. cp -sfr with an absolute path can probably create them, but I built a new pH.file.lncopy function in Python (using my pH.file.find) and had it run from a lnfix program with the paths in it. My lnfix utility is superior to cp since it will do incremental updates, and skip version control directories. The build tree points to the git repository, which keeps generated files (object files etc.) out of the repository and allows use of the Gentoo build directory and tools with my local modifications, and makes it proof against random cleaning.
The Visual Studio (2010) development environment. Now, working at Microsoft you'd think I'd use it at work, but I only use it as a debugger; I use Source Insight as editor and Office has its own build system using perl, build.exe, and nmake. I was looking for an IDE instead of my usual Vim in GNU Screen over PuTTY. I tried a few free ones, such as Komodo Edit, and found them lacking (e.g., Komodo Edit liked to randomly screw with my project's files), so I decided to try VS for XBMC (over a share). Fortunately there was a VS solution and projects in the tree already, and it scanned things in reasonably quickly. I did run into a bug where it wasn't finding includes (and hence definitions in them) in relative paths—"go to definition" didn't work, but oddly the code definition window did—but I added in some absolute paths and it sorted itself out.
I was forgetting to set "expandtab" (Vim setting to use spaces rather than tab characters) when editing XBMC sources; but I found a recommendation on StackOverflow.com (a site where more and more answers to my technical web searches tend to be located) for the local_vimrc Vim plugin, which searches up the directory tree for an applicable settings file (with some security checks).