Strictly, a Scheme programmer, but often also any pragmatic practitioner of functional programming. Schemists are distinguished from Lispers in their search for small, elegant solutions, almost always involving higher order functions. Unlike most functionalist programmers, a Schemist will use macros to create "syntactic sugar" for these higher order functions (Lispers use even more macros, but almost no higher order functions).
As an example, a good programmer might well cache the result of a frequently-used pure function (i.e. a function with no side effects). A Schemist will, instead, memoize the value. The difference is more one of terminology than of implementation, but it goes deeper than that: a Schemist's solution will tend to be written more generically -- it may well be a completely general cache. It will also be considerably slower...
Other programmers who might well be considered Schemists are most ML programmers and the Perl programmers who tend to functional Perl. (However, Perl Schemists will never produce perlous code!). Python programmers want to be considered Schemists; unfortunately, the lack of any real lexical scoping makes their claims very hollow. Common Lispers aren't Schemers, and proud of it. Emacs Lisp hackers aren't Schemists, and don't know any Schemists or what a Schemist is. C++ programmers would love to "implement the Schemer pattern" in their next program, but in practise they're too busy debugging their 57-line error messages from template meta-programming to have time to discover what Schemers are. Java programmers think it's something to do with multiple inheritance, and therefore that Java does it better because it doesn't have multiple inheritance. VB.NET programmers are too busy scheming to destroy the lives of productive software developers to care.