In my first attended session at Druaplcon 2008, speaker Chad Phillips started out with the basics of Drupal features including forms and the idea of separating presentation from content with themes.
Obviously, if you're going to be developing in Drupal, you're going to want a place to do the coding. Setting up an AMP (Apache + MySQL + PHP) stack locally is a quick way to set up a development environment that can be modified without mangling your production site. Versions of AMP stacks are available or Windows, Mac, and Linux as WAMP, MAMP, and various basic linux installs. The usefulness of phpMyAdmin on the local site is not to be overlooked.
For coding, a programmer's editor is really required equipment. When choosing an editor, choose one with debugging support and one that lets you code closer to the machine, so that you can edit things directly on the server if need be.
Using code conventions is important because in makes code reading common across developers. Increases security because its more obvious where errors are if the code is organized correctly. Makes it possible to commit changes to core code.
Drupal also has support via IRC. Use #drupal for general topics, #drupal-dev for discussing specific development topics, #drupal-support for questions starting with "How do I...?", and #drupal-themes for help in building themes.
The Drupal Dojo has screencast videos to provide training to users. Check out drupaldojo.com
Drupal's own API Module helps with code documentation and PHP documentation by creating references from the PHPDoc comments in the code. This is an interesting module in deference to PHPDocumentor, which pulls the same kind of information, but this integrates it into actual Drupal output. Using this module locally allows you to develop locally without requiring access to the internet, so you can develop on a plane and still access the API documentation. Running the API module with locally installed modules will also bring in all of the documentation from those modules, which you normally aren't able to get from the Drupal.org's own public API reference.
The Devel module is a helpful development module that allows you to completely clear the Drupal cache on demand. It can present to you a list of variables in the variables table, and let you change the value of those variables. It can capture emails that Drupal tries to send, and store them in the log without sending them, which is really useful if you've got a local site running for development and don't want to email your clients while you're testing. The devel module can output all o the queries that run for a single request, showing all of the replaced values and the duration of query execution. When it displays the queries, it can filter them to show only the ones that take longer than a certain amount of time, so that you can optimize them to increase page load speed.
The devel module is what you can use to display a call stack and backtrace in an error which is rather helpful for sorting out really hairy issues. There are quite a few useful features in the devel module for development, and it may be worthwhile to look into whether you're doing actual development or just building a site. The devel module has additional features if you're using Drupal 6, including theme editing.
The Content module allows you to create a bunch of sample content without having to create nodes that have Beastie Boys' lyrics.
A Coder module helps you code to coding standards and can assist in upgrading your module code between versions of Drupal. Another session will cover this module in more detail, so this one wasn't covered at length, but sounds interesting.
The Simpletest module will automate unit testing by executing test classes that you write to test your modules. Another session will go into detail on this module as well, and I'm thinking of attending that one later.
Chad offers these tips: Learn how to use CVS by reading the CVS handbook at drupal.org. I'm not sure how learning about Drupal's CVS structure is useful for you own Drupal development, and would actually prefer to keep my code in Subversion because, in my opinion, it is superior to CVS. Chad didn't really detail why you need to know this, but I suppose it would be handy if you were going to contribute to Drupal or contributed modules directly, since everything in Drupal is still using CVS. Knowing Subversion basically gives you the knowledge you need to use CVS, so better to learn the better tech and then use CVS only when it's necessary, I feel.
One thing he does cite as an advantage in reviewing Drupal via CVS is being able to see intended changes in future versions of Drupal and its modules. A diligent eye would be required to keep track of this kind of thing.
One thing Chad says about Subversion is that Drupal has many man-hours invested in using CVS as a tool, and that there are project management features that are integrated into Drupal as modules. Since these all depend on CVS, changing Drupal repos over to Subversion wouldn't be as simple as switching just the repo, but also all of the dependent modules that publish API deocumentation and such from the Drupal.org site. Very time-intensive.
Cool tip: Copy the first two lines from Drupal's main index.php to a new file, and add anything you want after that to test its working in Drupal with the full functionality it provides. It allows you to test easily without running everything and producing page output. You don't get all of the nice themes on output (unless you call them), but you do have access to things like the database and any active module. Great idea for debugging a tricky snippet of code.
Chad finishes up with some basic debugging information, using exit() and print_r() for testing.