i think this is what i was getting at. while i won't pretend to say my skills hold a candle to yours, i can tell by looking at the old codebase at this company that i'm the most experienced person that's been there ... i know i need to do more to document things, but i'm always stuck in the trenches.

i do tend to write a ton of little toy scripts to make sure function X does what i thought it did ( my homedir is full of them ), and refer back to them when needed.

i want to leave behind a way that people can learn something as well as have tight code that works properly.

just to clarify -- i don't think mainentance programmers have to be of a 'lesser' skill set than the original developer. i'm also a big fan of the Kernigan quote mentioned in another reply, and it has proven true at this job, because i've fixed longstanding bugs that the original (no longer at the company) developer just couldn't fix.

overcoming the managerial resistance is the biggest issue at this place. i've had a hell of a time convincing him that we need things like *shared* libraries, better source control, etc. because he's more concerned with ease of tossing a client their code if they leave than with making the developers' jobs simpler and easier.