The converse of PickTheRightToolForTheJob. If you like programming in a certain language, then find something to do for which that language is a good way of implementing a solution. The very, very important part to remember is not to overrate your chosen tool! Just because you know how to implement X in Y doesn't mean it wouldn't be a better idea to leave X to some other programmer with a different tool and go off and implement Z in Y instead.
This works best if you're contracting, since you can find new 'jobs' easier. =)
Choices such as these are often made for political or marketing reasons. Your supervisor may insist that the project use some particular tool/technology, despite the fact that it makes no sense or will bring additional cost, because it is desirable that your company be seen as being on the forefront of technological innovation (also known as JumpingOnTheBandwagon?).
In such situations, try to take some control and use the tool only for those things for which it is a good fit. Usually, the supervisor only needs to be able to say "We are using X on this project", and won't insist that it be used for everything. Use it for some non-critical component, call it a "PilotProject?" whenever anyone asks about it (managers love pilot projects; it makes them think they are shepherding a high-tech research endeavor), and whatever the result is, talk a lot about the valuable experience gained by the team while using it.