One of the principals listed in Extreme Programing Explained is the idea of Self-Similarity (taken from Mathematics and fractal geometry).  The idea in XP is to copy the structure of one solution into a new context, even at different scales, and is often used to help think about testing, and forms a good starting point for thinking about what structures or processes to apply.

In the Ephox development team we do this at a number of different levels.  We practice reflection regularly at a weekly basis with a weekly retrospective.  On a roughly quarterly basis we review our current state of play from a process/methodology standpoint.  We will often look back over things at a small level with coding. I've recently noticed myself doing the same thing at a micro level, helping myself to learn keyboard shortcuts for IntelliJ.  

In summary, some of the good spots for reflection for a development team are:

• Weekly - helping to see what can be done to learn from the previous week and do better in the next week.
• Quarterly  - helping to see what can be done to generally improve process, taking a bigger picture view.
• any-time - when you notice something that is interesting (for example a pop-up in your editor) stop and reflect on what has happened - you might just learn something.

 Reflection is a great practice to follow at different times.  When do you find reflection useful?

..is cmd-opt-F7 (in Mac)

CMD OPT-F7 displays a list of  usages of the currently item (var/method) throughout the project, listing them in a nice inline dropdown list.  This is great for navigating around the usages of a method finding how they are used in context, before applying an aggressive refactoring.  I discovered the short cut recently while performing one of the other find usages options in Intellij (cmd-F7) and getting fat fingered and hitting CMD-OPT F7.

Or finding which websphere portal shared jar contains the class you need.

When trying to find which WebSphere portal jar file contains the PortletServiceHome class (for the unitiated there are 225 jars in the portal shared directory), I was pushing my very rusty shell scripting skills.  I pulled in Doug for some advice, and we were working through various sledgehammer approaches and talking to google about what to do.  We were playing with various combinations of pipes and shell commands to get the output of the find (or ls) to play with the jar tvf and grep.

AJ then piped in with just use grep, and he really meant.. just use grep, and take advantage of the fact that the contents of the jar will be listed in plain text in the jar.

The command I ended up with was (running in PortalServer/shared/app):

grep PortletServiceHome *.jar

Which returns:
Binary file wp.pe.api.standard.jar matches
Binary file wp.pe.rt.impl.jar matches

Then running jar -tvf across the first jar shows that this is what I need to compile against and work with when developing.

The bulldozer of a grep across jars is the best way to find which jar contains a class that you are looking for1.

1 - While this feels really inefficient, it is actually better than having to spawn off multiple the jar processes which other approaches would involve. ↩

While reading a Java Diagnostics guide for a unnamed JVM I saw this:

Who should read this book

This book is for anyone who is responsible for solving problems with Java(TM).

Somewhat less than useful