I would say that you might well have crossed the line from a "Programmer" to something more complex. Some people use the term "Software Engineer", however others feel there should be a lot more stringency on the use of that term.

Much of the existing writing on managing software development argues against having the Developer themselves responsible for all the aspects you list; This is for both focus and issues regarding organizing a team.

Exactly how would it work if each programmer in a 20 person team was responsible for defining their own time tables and deliverables? Some sort of consensus would have to be achieved, correct? There is usually an individual assigned this role in a team, often the team lead or the project manager. While a developer can handle this task, it is often a better use of resources if the developer is allowed to develop rather than worry about organizing time schedules. There are people much better suited to this role, who can focus on it. While I do empathize with the situation that often the people who are given this role, often are not well suited; But this is a problem with the Co. assigning the wrong people.

It is well documented that a developer is often the worst tester of their own product. Unconcious bias relating to certain sections of the code which are unstable can creep in, personal opinions regarding ease of use and desired functionality can arise from a misunderstanding of specs, as well as the time required for testing is often business-wise much better done by someone the company doesn't have to pay as much. A QA dept can build a standard procedure and reporting chain, which when done right will result in a better testing of the product -- assume the QA group and programmer have the same testing skill, the difference would be the benefit of having an unbiased set of eyes to examine the product, and if the skills are not equal then the QA group needs to be better trained.

During the QA process, the testing team will need help from the programmer in understanding the details of the system and often in how to test functionality
This injects the programmers personal bias, and restricts the QA teams efforts. A QA team should proceed as a user, not as a knowledgeable developer. A QA teams job is to be the best BDU you can find, if you educate them too much about the system then you eliminate much of their value.

Spec gathering, this is part of a system designer's job. However, how time consuming and redundant would it be for each programmer in a 20 person team to do their own spec gathering? Quite. Even if they only gathered specs for their own particular section, there is always going to be overlap and it is quite possible that transition issues within the system would be overlooked. So, again the management of this process should be given to a single individual ( often the project manager, but sometimes an analyst ), which can bring in team members as required but in general leave the developers to develop.

From reading your view it seems that you either work in an extremely small development shop where you are the only one, or maybe one of two, on a project. Having the individual developer responsible for all of these tasks simply does not work for larger development teams and is often a collosal waste of resources.

I have experience developing in Co's with both large and small development teams. The Co is much better off in software development when they can afford to staff a team with developers, a project manager, a relationship manager, an analyst, a documenter, and a QA team ( yes multiple, not just one ).