Your code is clearly too complicated. If you can't glance at it and tell what's going on, it's too complicated.
I disagree. The phase of working out the details is usually a bit messy if you're working on any kind of involved code. Whether you're working out the details on paper or at the keyboard, alone or with somebody else. You need to go over it a few times and shuffle things around as necessary.
That doesn't mean that the resulting code is messy. I'd say what I end up with is usually very minimalist, understandable and to the point. Write it out verbosely, cut redundancy afterwards, condense where possible, optimize where necessary.
Or can you actually write everything straight, from start to finish, without changes, completely optimized?
You always have a phase where things are rather in flux. I happen to go through this phase at the keyboard. With a second person I'd go through it verbally or on paper, then implement it in code when we can agree on a good solution. Either way, one person is writing the actual code. I don't see a need for somebody looking over my shoulder during that time.
It's great to bounce ideas off of another experienced developer. It's great to discuss advantages and disadvantages of certain designs over others. But writing a block of code that implements these design decisions without bugs and to the specs/idea should be well within the capabilities of a single programmer.