I made that choice myself just after college, and after doing this gig for quite some time I have a better feeling for why that's a good fit for me. When I spend days pounding on some complex script for a large upgrade, the closest I get to true programming these days, the hours fly and I come home aggravated because the problem isn't done yet or is vexing me somehow. I find the prolonged stress hard to take.
Contrast this with SysAdmin work, where the stress is more, shall we say, peaky in that the stress lasts for a few hours and goes away once the problem is resolved. We do have some cases of continual stress (upgrades that take a week, enduring failing hardware in your backup environment causing backups/DR to be unreliable), but generally they are exceptions rather than the rule. Its easier to keep an even keel for me.
As Joel K put it:
These jobs aren't completely orthogonal. A good Sysadmin will spend time writing tools to help automate their job. A good developer will understand how a system runs and write code to suit.
I find that knowing how a system runs is actually highly beneficial to me as a SysAdmin. It's just that the systems I need to know how to run are commercial off-the-shelf software for the most part. I routinely blame my Computer Science degree for that, since I have a good understanding of how software works it makes it easier for me to figure out where it breaks. This is also what makes me a good QA/Beta-tester, by the way.
In my opinion a programming background gives you a pretty sound foundation for the software troubleshooting aspect of SysAdmin work. The parts you'll have to work on are hardware troubleshooting, operating system troubleshooting (unless your dev work involves OS or drivers, at which point you're golden), and just plain best-practices. Best-practices are for the most part on-the-job-training, though you can get some of that through certifications.