CodeGnome gave a very good answer, but I have a little to add.

I don't think it's impossible to take on both roles at once. I actually do that myself, and having previously worked exclusively as a developer, I am seeing that I can bring about improvements both within the team, and the wider organisation.

However it does limit the impact of the Scrum Master, and there are certainly some conflicts of interest. Development Team member and Scrum Master are separate roles. They may have the same ambition of delivering value to the business, but the ways in which they do this do not always overlap. For instance, a Development Team member might focus on the Sprint Backlog as the best way for them to deliver value; a Scrum Master may focus on systemic matters, and could, for instance, take a longer-term view. This is most sensitive when the team are under pressure. A Scrum Master may be required to focus on protecting the team and their system of working. A Development Team member may be expected to focus on work in the Sprint Backlog. Depending on how the Scrum Master has been empowered, this may result in them not being able to do their job.

The Scrum Master is described as a servant leader, and as such, it is a legitimate tactic of a Scrum Master to avoid interfering too early, when they notice a potential problem in the way the Development Team are working. The rationale is that it is better to let the self-organizing Development Team see the impact of this way of working, and then take responsibility for implementing their own solution. The conflict here is that as soon as the Scrum Master has seen an issue, one member of the Development Team has too; but it doesn't necessarily mean the other members of the Development Team recognize the issue, or will be convinced of the need to make a change. Given that the Development Team's focus isn't on understanding Scrum systems as a whole, it is likely that in many cases, the Scrum Master will detect an issue before the other Development Team members. The risk of raising the matter too soon, is it may deny the remaining members of the Development Team the opportunity to understand the problem, and fully self-organize; but waiting too long might undermine an expectation of all Development Team members to raise issues when they see them.

These conflicts do not prevent one person fulfilling both roles, but in the spirit of openness (one of the Scrum values), it would usually be wise to identify and discuss them with both the Scrum team and management.

It is also likely that specific conflicts will arise over time, depending on the nature of the organization and individuals involved. If they can't be eliminated, identify and acknowledge them.

Todd gave a very good answer, but I have a little to add.

I don't think it's impossible to take on both roles at once. I actually do that myself, and having previously worked exclusively as a developer, I am seeing that I can bring about improvements both within the team, and the wider organisation.

However it does limit the impact of the Scrum Master, and there are certainly some conflicts of interest. Development Team member and Scrum Master are separate roles. They may have the same ambition of delivering value to the business, but the ways in which they do this do not always overlap. For instance, a Development Team member might focus on the Sprint Backlog as the best way for them to deliver value; a Scrum Master may focus on systemic matters, and could, for instance, take a longer-term view. This is most sensitive when the team are under pressure. A Scrum Master may be required to focus on protecting the team and their system of working. A Development Team member may be expected to focus on work in the Sprint Backlog. Depending on how the Scrum Master has been empowered, this may result in them not being able to do their job.

The Scrum Master is described as a servant leader, and as such, it is a legitimate tactic of a Scrum Master to avoid interfering too early, when they notice a potential problem in the way the Development Team are working. The rationale is that it is better to let the self-organizing Development Team see the impact of this way of working, and then take responsibility for implementing their own solution. The conflict here is that as soon as the Scrum Master has seen an issue, one member of the Development Team has too; but it doesn't necessarily mean the other members of the Development Team recognize the issue, or will be convinced of the need to make a change. Given that the Development Team's focus isn't on understanding Scrum systems as a whole, it is likely that in many cases, the Scrum Master will detect an issue before the other Development Team members. The risk of raising the matter too soon, is it may deny the remaining members of the Development Team the opportunity to understand the problem, and fully self-organize; but waiting too long might undermine an expectation of all Development Team members to raise issues when they see them.

These conflicts do not prevent one person fulfilling both roles, but in the spirit of openness (one of the Scrum values), it would usually be wise to identify and discuss them with both the Scrum team and management.

It is also likely that specific conflicts will arise over time, depending on the nature of the organization and individuals involved. If they can't be eliminated, identify and acknowledge them.