Module weights sometimes come into play when you're trying to override certain aspects of the core or other modules. If you look in the Drupal database's system table you'll notice a field called weight - this is what determines the order in which all of the installed modules' hooks will get called during a page request.
I was writing a module to conditionally hide a fieldset on a CCK node editing form based on whether the user is logged in or not, and for a while I was very puzzled as to why my custom module's implementation of hook_form_alter wasn't seeing any of the fieldsets defined by the CCK fieldgroup module.
I searched Google for the terms 'cck fieldset hook_form_alter', which led me to a helpful tip from Benjamin Melançon:
If you want to see what's going on when Drupal's cron.php script runs, one thing you can do is to set a breakpoint in a module's implementation of the hook_cron() function, and call cron.php directly from your debugger. There you can step through your breakpoints, examine variables, and hopefully zero in on your problem.
It’s easy to take Drupal’s built-in user management features for granted… out of the box, you can configure your site to allow user registrations, reset forgotten passwords, and handle user logins. We had a use case where we wanted to combine the login and registration forms into a single landing page for anonymous users, to encourage users without an account to sign up with a single click rather than hiding the registration form behind another link.