|The stupid question is the question not asked|
For a while, I've felt that writing good software must involve at least three people: a coder, a user interface designer, and a tester. However, most of the Perl projects I've worked on professionally have been lone-wolf projects. A manager has said, "Stephen, here's a hammer and some nails; build an ocean liner," and I was off on my own. After doing this for a bit, I've come up with a method of getting some of the benefits of working with a team without adding anyone else to the project.
One of the main reasons that there must be multiple folks on a project team is that it's possible to know too much about the whole project. For example:
However, in a pinch, I've learned to avoid some of these problems with a bit of self-induced multiple personality disorder. (Multiple-personality disorder seems to be real, and I don't mean to trivialize it by bringing it up here.) With a bit of method acting, one can keep the designer's persona separate from the coder's. The techniques are simple and subtle, and probably many people use them without thinking about it. Drumroll please... the techniques are:
Consciously switch roles. When you've been coding for a while, and are switching to testing, take a second to remind yourself that whereas before bugs were bad things that you didn't want to see, now they're good things that you WANT to see. Think of yourself-the-coder as "that lunatic whose code I need to check." Don't let yourself change user-interface requirements because it's a little harder to code that way; think of how yourself-as-interface-designer would yell at you if you did.
Keep phases distinct. Work in different subdirectories depending on your role. Use different tools. Put HTML in templates and use an HTML editor to edit them. Automate your unit tests so that yourself-as-tester can work alongside yourself-as-coder easily. Using different tools and environments for different jobs makes it easier to remember who you're supposed to be right now.
Finally, it's sometimes useful to think of yourself as the manager of this little hallucinatory workgroup. Being the imaginary manager can give you some much-needed perspective on what you're doing, and can make it easier to give accurate answers to requests for time estimates.
(Just don't be your own pointy-haired boss...)