The scouting motto "leave the world a little better than you found it" applies perfectly to software. Often this is used to encourage programmers to clean up the mess left by past programmers, but it works in both directions. It is also the responsibility of all software engineers to leave future programmers better off for having worked with their code. It is our duty to teach, even if we don't ever talk to our students.
Reg Braithwaite writes about how to decide whether or not to use a technique, tool, or language for your project. Engineers must consider the context in order to make this decision: who we work with, what we're doing, and why we're making this decision in the first place.
My overriding concern is not for the current project, or the people I'm working with now. It's for the future programmers I won't meet, who will have to work with my code. I want them not just to be able to fix bugs and add features, but to learn something too, just as I have learned from the code I read.
This is a subtle goal which is difficult to achieve. To teach through code, you must stretch the reader, but not too far. It is counter-productive to use techniques so far removed from the norm that they make no sense in context. We must consider the programming culture we're working in, and this is difficult to do. I have no advice here, except to do what you think is right.
For this reason I think it is vital to broaden your horizons as a programmer. Learn about functional programming, about array languages, about declarative logical programming, about microcontrollers and interfacing. Learn about things I haven't even heard of, and teach me by writing programs.