These days? A programmer that does anything but CRUD for web apps.
In the before times the terminology came from system 360 and descendent mainframe systems where the system programmers tended to be intimately involved with the deployment and programming of the operating system and associated "exits", and such tasks tended to presume some working knowledge of assembly language (operating systems were very crude at that time...and many shops tended to "customize" them if that makes sense...you would sometimes have serious problems with operating system level things and at that time the generic response would be "contact your systems programmer", who would either fix it or get in touch with IBM...so TLDR is basically a sysadmin that is good at assembly). Big companies could afford to have systems programmers on staff and needed them because every shop was different and computers were very custom and crude at that point in history.
That's where the terminology came from originally but now it has expanded and can mean different things.
The "systems programmers" terminology was mainly just a differentiation from the more generic "application programmers" (who would probably program in COBOL or something similar, doing business related tasks) or "system operators" (who would not usually be programmers at all, and would do a lot of what we would now consider sysadmin work).
Nowadays it just means anything that isn't bog standard CRUD or frontend web app stuff. The terminology has evolved but has a somewhat similar meaning to when it originated. It's tough to understand exactly without the historical context which is why I have included that.
For obvious reasons, this has some overlap with the more modern definition of "programmers that build systems that other programmed then use". Because the application programmers on those mainframe systems would be relying on the systems programmers to not screw up their assembly wizardry or else everything would fall apart.
In the before times the terminology came from system 360 and descendent mainframe systems where the system programmers tended to be intimately involved with the deployment and programming of the operating system and associated "exits", and such tasks tended to presume some working knowledge of assembly language (operating systems were very crude at that time...and many shops tended to "customize" them if that makes sense...you would sometimes have serious problems with operating system level things and at that time the generic response would be "contact your systems programmer", who would either fix it or get in touch with IBM...so TLDR is basically a sysadmin that is good at assembly). Big companies could afford to have systems programmers on staff and needed them because every shop was different and computers were very custom and crude at that point in history.
That's where the terminology came from originally but now it has expanded and can mean different things.
The "systems programmers" terminology was mainly just a differentiation from the more generic "application programmers" (who would probably program in COBOL or something similar, doing business related tasks) or "system operators" (who would not usually be programmers at all, and would do a lot of what we would now consider sysadmin work).
Nowadays it just means anything that isn't bog standard CRUD or frontend web app stuff. The terminology has evolved but has a somewhat similar meaning to when it originated. It's tough to understand exactly without the historical context which is why I have included that.
For obvious reasons, this has some overlap with the more modern definition of "programmers that build systems that other programmed then use". Because the application programmers on those mainframe systems would be relying on the systems programmers to not screw up their assembly wizardry or else everything would fall apart.