When I started working at Mikros Image in Montreal, I knew only the most basic and fundamental things about Python and hardly any MEL at all.

I feel responsible for salvaging and recording some of the lessons I've learned through my experience over the past year. I think there's untold hours spent educating myself, so I think the best way is for me to describe some of the topics I have learned in the process of writing scripts and tools for myself and my department. 

...Here goes!

An interesting script I dug up today.

There was a situation where I needed to select a number of random edges from my selection to create some geometry for a more randomized effect. I didn't want to have to do it over and over again, so I wrote some quick scripting to work on the components I had selected.

I sat down and expanded on the code I started with and wound up creating a script which works not only on the selected components, but on all things selected... components, geometry etc.

I don't see any problems with this script right now. Not the cleanest implementation of the idea I think, but -shrug- that's why we learn while we're developing.

I hope someone finds it useful!

Here's another one I found. - <Had to remove because link depreciated>
Fun trying to use dictionaries.
Someone who is working with particle emitters in Maya might be familiar with the frustration of "Emitting from object" and using surface emitters and then realizing that the surface you're using is not the best shape or object for the emission.

With this script, you can select your emitter and a target surface, it will disconnect the current surface and replace it with the new surface.

One of my assumed responsibilities from work was to write scripts for my own use and the use of members of my team. Now that things are winding down for me at this job, I'm going through my scripts and trying to salvage usable modular code.

A few thoughts while I'm doing this...
- Write things cleanly the first time and save some grey hairs trying to figure out what you did, why you did it, and whether you could use it on a new project later on.

- Think through logical iteration/algorithmic process before creating endless exceptions with "if <variable> == <value>:" statements...

- Raise descriptive errors if the code is executed in ways other than expected and just... dies.
(Prevents: "...uh... um... huh? <opens code, eyes glaze over>" scenario)

- Comments. What did you want to do with that function?

- Doing something more than once or twice in your function? Write a new function to handle it.
    - Add comments to explain dependencies...

- When writing tools, try to compile commonly imported self-written functions/modules to reduce the amount of gopher-tunneling.

- If there is some condition or situation needed when running script, comment on what it was.
("Oh... this doesn't work... why? Oh, because the curves selected need to be dynamic and their output has to be named with '<very specific suffix>' ...okaaaay, even though that script might have been useful, there are too many other things I need to look at to spend time setting up that situation to test the script.")

- For the love of God, comment and date updates to code in the header. Less of an issue if working with a release system or git repository or whatever which keeps track of changes. For little personal code which may be saved in more than one place, keep track of the dates and changes made. Can help prevent needing to solve the same problem/bug again.