We're lucky that we work in an industry where our work is most likely not going to kill people. We don't have to be licensed to make a claim of who we are or what we can do. But it would be very disingenuous for me to call myself a professional software engineer just because i've written hundreds of thousands of lines of code, and for you to call yourself a sysadmin because you've set up some software. The mark of a professional is understanding at a deep level all of the hidden detail that goes into the work, and if we hold them up to a standard, the titles will reflect that.
So, how often are software developers different from sysadmins? They're always different. They're completely different practices. As a person, you can indeed have two separate successful careers and become both, but that doesn't have anything to do with devops, which is merely the practice of dev and ops collaborating together.
"Set up some software," though? The condescension is both unnecessary and built upon some pretty shaky projections on your part. Can we not dance that dance, please? (ETA: Not least because I think your posts, for the most part, are really good and I have a lot of respect for you, especially around security topics.)
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.
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.
Chef etc. aren't "home repair." (Well, maybe Docker, and it shows.) They're a way of expressing subject matter knowledge. Still gotta be a developer to do that expressing in a way that isn't going to kill you, either directly or because you write code that your fellows burn you at the stake for.