Here’s a few tips that I think are useful to IDL programmers who have basic knowledge of IDL, but want to start doing more sophisticated tasks.

1. Use objects. I suppose I should write a more lengthy defense of object-oriented programming at some point, but for now, I think it it clear you have to resort to a lot of hacks and work-arounds if you never use objects.
2. Document the interface of your code (for example with IDLdoc). It’s handy to have a searchable, browsable collection of (at least) your routine headers. Better yet if you put in documentation to explain what routines do, what the arguments are, etc.
3. Test your code (for example with mgunit). You’re going to run your routine at least once to make sure it works anyway, right? Why not put that code in a file that can be run as needed to make sure your code still works after IDL updates, changes to your code, changes to underlying libraries, etc.
4. Put an example main-level program at the end of your code. Placing a main-level program after all the routines in a file is an easy way to put a working example in the code. Run it from the IDL prompt with: .run filename.
5. Don’t crowd a widget program’s “state” structure with widget IDs and object graphics references. Use find_by_uname (for widgets) and getByName (for object graphics) to find them.
6. At least be familiar with some of the tricks involving HISTOGRAM. Know enough to realize when you need to start looking at through the histogram tutorial.
7. Use conditional breakpoints.

I don’t believe they are available from the Workbench interface anymore, but the BREAKPOINT routine still allows them.

I previously made a similar list of tips for beginners.