I agree, on both counts--and you should write the least code possible and reuse the most tools possible when you're building a web app, too! And when I am managing systems and infrastructure, I am reusing tools that are configured and operated through the expression of domain-specific code in Ruby. When I'm solving a problem, I'm writing code in Chef or in Cfer/CloudFormation (if I'm touching a machine by hand that's outside of my burn-it-down test environment, something's going really, really wrong). I'm consciously writing that code in such a way that I can put it into an automated test environment based on preconditions and postconditions that map to the business logic of the system to ensure correctness when that code is then changed. If I need to solve a related problem later, I'll generalize the code for least-effort reuse at that point.
This is literally software development, to me. That the output involves a configured system instead of a web app or whatever is orthogonal to being software development. It still feels like you are drawing a distinction without a difference.
In actual fact, the complexity of software design is antithetical to the job of system administration. If at all possible you should use the least code possible to do a given job, and rely on the reuse of tools to serve various functions. This is not coding, just like auto repair is not engineering. If you're writing code you are not adminning, you are developing.
There is a time and a place for software development in Ops, but it should be based around projects led by teams to serve specific functions that existing tools won't solve, again similar to auto repair because some tools are needed simply to repair things more efficiently, but then you use those tools and don't keep engineering new ones. The distinction is small but highly important, because code is often a source of headaches in Ops. This is coming from a guy who is usually hired to write code for Ops departments.
A software developer can of course perform some of the functions of a sysadmin, but again the complexity of the whole becomes too much to understand just by doing single tasks. Either job is too complex to learn without a lot of study.
I just find comparing the two in the context of one becoming the other invites oversimplification of either role, and devops doesn't help that comparison.