There's reasons we have these classes of people with certain labels. Until the 18th century, buildings were designed and built by "artistan craftsmen", people who had no formal training or education in building things (or in any capacity) but said, sure, I can make you a house. Then it would fall down and kill a family of five. All around the world today, architects and engineers are required to be licensed and prove they know what they're talking about so this doesn't happen. As a result of this process, the whole profession developed and advanced the state of how we build things.
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.
I've read your post two or three times now, and I straight-up don't get what you're driving at. Yes, there are levels of subject matter expertise that you need to know--or at least be conversant enough with to deep-dive when necessary--for system administration. That's also the case for database programming or bioinformatics or graphics programming or whatever. But it is still expressed through the writing of code, in 2016--and that code, largely today and with increasing focus going forward, needs to be well-structured, testable, so on and so forth. It is still the development of software. It's a specialization within the same field. It may not have been twenty years ago; if it isn't generally today, it will be before I retire, and probably a lot sooner than that. And to that end, the question that was originally asked makes a lot of sense, to which the answer is "a sysadmin is-or-had-better-be a software developer; a software developer may or may not be a sysadmin."
"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.)
I would be horrified if you had to be a software developer to be a sysadmin. It would be like requiring an auto mechanic to be an engineer, or a cook to be a chemist or something.
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.
> 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.
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.
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.