Actually, I think working on many PCs can increase your productivity (albeit not without an initial investment).
The reason for this is complex, but you can sum it up this way:
You are forced to think about creating a good development environment, independent of your PC.
I'd argue in better-organized companies this is the case and there are documented instructions about setting up a new computer up to speed with the tools required for the project developed.
In order to achieve what you want, you should decouple your process from the machine as much as possible.
So, a couple of tips:
1. Always use version control.
This applies to both code and data. Tools for the code and data differ, of course.
You might want to favor distributed tools, since this gives you more flexibility.
2. Document the process of setting up the development environment
This is pretty straight-forward, although admittedly it's also time-consuming. However the importance is utmost: if you suddenly have to setup a new machine, this is immensely helpful.
3. Create a VM containing a ready development machine
This is rather an emergency response step, but it's very good to do that, too. This way, you can just start coding when presented with a new PC, which can save you much time if you're in a hurry.
4. Have a dedicated deployment / continuous integration server.
This way you can assert that the code works on the deployment machine as well as yours. There are many service providers for this, plus dedicated virtual servers are not very expensive anymore.
5. Use a cross-platform IDE (if possible) and learn how to cross-compile and cross-debug (if applicable).
Again, allows you to work in an even more unfriendly environment, plus this is the only way you can catch some of the more persistent bugs. It allows you to do stuff like leave your work machine on when leaving the office and debugging on it from home, even if you can't run the project locally.
6. Make yourself comfortable with SSH, VNC, SCP and RDP.
You're going to need at least one of these, since there's always some mixup when a deadline is approaching: a file you've forgotten to upload to the server and is on a PC in another city, or you need to fix something on a remote machine, etc.
Think of #6 as a last resort; you shouldn't depend on anything you don't have easy access to for your work, except in unforeseen cases, and SSH is not easy access.
Accidentally, you might notice some of these tips are considered good practices in general; I believe them to be such. This is all a matter of organization and improving it will save you time, eventually.