If a programmer in a small company wants to be his own Scrum Master, and Scrum teams are supposed to be self-organizing, does that mean no one can manage him? If that's true, then:
In the same way that a UX designer is responsible for creating an excellent user experience, a Scrum Master is responsible for creating an excellent project experience for those people who use the team to turn their ideas into reality.
By looking at the "team" from the external perspective, we can easily narrow down those bits of Scrum that are relevant even when the team is made up of one person.
A Scrum team provides:
If a team member is working as his own Scrum Master, he can still provide these things by keeping a visible Scrum board, meeting with the stakeholders to prioritise work, working towards the Sprint showcase, responding to feedback, and releasing valuable software. How he chooses to do that within the limits of the Sprint will be his own business, just as it would be the team's.
If a single programmer is also working as his own Product Owner - for instance, he owns a one-man company - then he won't be constrained by the need to communicate with external stakeholders. He can create his own priorities, release code as-and-when, and get feedback directly from his users. In this case, I'd look at Kanban, simply because of the focus the WIP limits provide and the more flexible cadence.
While you could use Scrum in a one-person shop, Scrum is really a framework that's designed for teams rather than individuals. The underlying inspect-and-adapt philosophy is also available to a one-man shop using Kanban or Extreme Programming (XP); XP in particular is often a great fit when you want agile practices rather than a project management framework.
The Scrum Master role is a process referee role. This is inherently a conflict of interest with the Team Member role. For the same reason that you have (theoretically) impartial referees in professional sports, the Scrum Master role should be separate from developer roles.
Project teams are always constrained by resources, scheduling, and (most of all) by organizational culture. "Self-organizing" is intended to be shorthand for a process where teams figure out how to do the work without micro-management; the organization still manages what work is to be done and what resources are made available to the project.
The remainder of your question delves into specifics of individual time management, prioritization, and reporting that are going to be localized to your particular work environment. There isn't a "one size fits all" solution; finding one that fits your company culture and individual situation is part of the self-organizing part of being agile.
