My tooling preference is evolving a bit. I used to hate IDEs, because I associated them with the (thank God it failed) attempt to commoditize programmer talent (starting in the 1990s with VB) that hijacked "object-oriented programming" and led to 21st-century spaghetti code. On the other hand, IDEs can actually be damn useful. You're in for hours of misery if you try to do Java development without an IDE, and IDEs are better adapted to one reality of software development: that most professional programmers spend more time trying to figure out other peoples' code than reading their own. The click-and-navigate capability (that automagically takes you to the file and line where a method or class is defined) is valuable.
Something Google had that I liked a lot is a code-navigation tool, much like a read-only IDE, served on the web, for its codebase. Very useful.
IDEs also help you navigate the dependencies and cruft-sprawl that are pretty much unavoidable on large Java projects. If you're on-boarding into an existing Java project and want to be productive in your first week, I think using an IDE is the only answer.
For my own projects (where I'll often use Scala but never Java) I still use emacs and probably always will, but if I'm working in a 100kLoC codebase of mixed Scala and Java, using a build and version-control system I'm not familiar with, I'm going to use the IDE, at least when I start out. IDEs aren't perfect: a lot of the things they hide or for which they automagically do the work (build system, version control) are things a programmer will actually want to understand at some point. But it's nice to be able to be productive (in a software environment you didn't create) on the first week.
Debuggers are another area where I'm coming to learn that printlining isn't always enough. The name of the game in debugging is not to break flow. Pinging about files inserting printlines (trying to figure out where to put them, and how to handle loops where you strictly do not want a printline for each time you're in the loop) can involve too much orthogonal thinking and context-switching to be productive, so an interactive debugger like what Lisp has or what Eclipse offers can be a godsend. Often printlining is the best solution because you know what you want to see in the execution (it's not "ad-hoc" debugging) but sometimes you don't. Once you start having to think about how to printline something, you're better off with an interactive debugger.
Unit tests, for me, are about not breaking flow. I'd rather do the debugging while the problem is fresh in my mind than possibly months later. I'm going to "REPL-test" the thing in any case, and I might as well turn that session into something persistent. I certainly won't remember, 3 months later, how comprehensive my REPL testing was. If I have unit tests, I can check and see what's covered and what isn't.
I don't write unit tests because I'm a nice guy. I do it because I'd rather spend an additional 20 minutes writing tests-- plus whatever debug time happens on account of bugs found, but that's strictly less time than it would cost me or someone else to debug it later-- than have to deal with a context switch weeks or months later to fix the damn thing.
As for Agile and Scrum, I think that stuff is mostly dopey pixie dust that's seems progressive because it's shiny and new, but most of it's neo-Taylorism, and Taylorism didn't fucking work the first time around. "Agile" is too ill-defined to mean much anymore. As for Scrum, structuring time into "iterations" is stupid (sure, you can call a 17-day period an "iteration" just as you can call an oblique trapezoid a "skwirk" and the class of mammals over 250 pounds "mforzas" but it doesn't mean anything), and most of this agile neo-management stuff can become a bog if (through benign neglect) it re-devolves through benign neglect into normal human behavior.
One example is stand-ups. If you're going to have frequent status meetings, stand-ups are the best way to do it. People tune out in meetings of more than 5 people except to communication directly affecting their work, so there isn't much learned in them. Stand-ups exist to encourage short status meetings rather than sprawling, boring slogs, so they're a useful innovation... when people actually stand the fuck up, If people treat it as a stand-up meeting (i.e. show up on time, actually stand, and only address issues that are directly blocking work) it can be useful, but if not, it just devolves.
The real purpose of stand-ups, by the way, is to prevent the issue where people delay communication on things they need out of fear or apprehension (that is, they're afraid to ask for what they need from people) and linger around being blocked on their main project, instead doing low-priority work. The purpose of standups is to allow people to say, objectively, "this issue is blocking me" and allow group pressure (rather than management fiat) to encourage resolution. It gives the blocked person an opportunity to state a blocking issue objectively without pointing a finger and the group pressure encourages people who have the power to resolve the blocker (who now not only know the blocker exists, but know that everyone else knows that they know, i.e. "common knowledge" in the modal-logic sense) to fix it. Without something like standups to force this, people with poor communication styles or avoidant personalities can end up lingering on low-priority work for weeks. So standups can be legitimately useful. On the other hand, most of this agile "magic sauce" is neo-managerial bullshit that quickly devolves into old-style bureaucratic muck.
For example, a lot of these "agile" startups that have standups have half the people not even standing up. It can creep into an hour-long sit-down meeting... except now it happens every day instead of once every 2 weeks. So now you're having 60+ minute long, boring status meetings every day, and productivity goes way down.