/usr/local, or backports, and package your own software.
I’ll start with a generality: a distribution release is a coherent unit. Obviously it exists to support what its users want to do on top of it, within reason (see item 4 in the Debian social contract), but it first has to support itself; in particular, the libraries it contains are there primarily because they’re dependencies of some other piece of software in the distribution, and the
-dev packages (or
devel for readers on the RPM side of the fence) are there so that the packaged software can be built using the distribution. When you’re building software on top of a distribution, if the libraries included in the distribution meet your requirements, that’s great, and you’re very welcome to use them; but if they don’t, you should avoid massaging the distribution to upgrade them.
Some development environments deal with this already: Python has its virtual environments, Ruby has something similar, Java and NPM manage their own project-specific dependency trees, etc. The C/C++ ecosystem doesn’t really have anything like this, apart from
/usr/local, which might well fit the bill in many cases, including when the compiler is too old.
In practice, in the C/C++ ecosystem, there are a few viable solutions.
If you need the bleeding edge, you can use an “unstable” system for your development. It doesn’t have to be your full system (you should only do that if you’re comfortable helping Debian develop its next release), a chroot works very well for this; also note that “unstable” refers to the ABI stability, not the general stability of the system.
If you’re comfortable managing your own dependencies manually, build your software and its dependencies (which aren’t available in the distribution) in
/usr/local (and check out tools such as Stow to manage versions).
If you just need a few upgraded dependencies, consider using backports. This answer will explain how to go about installing backports and even building your own; this will allow you to continue using packages in a safe way with newer versions than what you can find in the current stable release. This does scale quite well, and many organisations maintain their own repositories of backported packages internally.
Above all, it’s worth learning to package the software you’re building: doing this means that the distribution’s tools will help you ensure the dependencies remain available, which is very useful when you install your software on other systems, and when you upgrade. Vincent Bernat’s excellent pragmatic Debian packaging technique will help you get there quickly.