Do you use project management on your personal projects

You are in a frantic and desperate mindset. Take a few deep breaths, clear your head and contemplate the following facts (and if your mind leaps to counterarguments and panic, start over with the breaths).

1. If you're doing all the work, then they need you. If you die, so does their business.
2. If you're working late nights and weekends then you are working at an unsustainable pace, tending toward a steady state of inefficiency and poor work. If you were somehow able to work decent hours, you'd actually get more done per day and get things finished sooner. (If your brain just said "But my manager--!" then start over with the breaths.)
3. When your manager gives you an unreasonable goal and you half-kill yourself to get it done, you are rewarding him for his behavior. You will get more of what you reward.
4. "This cannot be late." Yes it can. Read this one over a few times.
5. Although you feel that he should reward you for hard work, you know that this is not true. This is not the path to success.
6. If the task is not completed by the deadline (see #4), which will look worse: A) you accept the task with the look of a hunted animal, work like a demon and then cringingly admit that it is not ready on time, or B) you tell him calmly at the outset, and every day that it will not be ready by that date, but that it will be ready at that later date, you work calmly and steadily, it is not ready at the deadline but it is ready when you told him it would be. (Breathe, breathe.)

The important thing here is your mindset: your goal must not be to achieve the impossible. Now that you can see there is another way, how do you communicate this to your boss? There are no miracles, but you can accomplish a lot by speaking his language.

1. Document everything you do. Seriously. Take a little time to do this, even though you are under deadlines.
2. Tech-illiterate managers love pretty pictures. Acquaint yourself with a professional-looking tool, one of those "schedulers" that they love. You must be able to produce timelines and graphs in pretty colors.
3. Learn some buzzwords, especially the ones he (or his boss) uses.

Now combine these things. When they ask you for a quote, work out a good one-- don't rush this--, pad it a little, give it to them, never ever negotiate a time estimate and whip up a timeline showing it. If possible, use the graph as your reply (if you can get them to start using your graphs, you've half won). If they outsource the job and you have to fix the problems, give them a quote for that, whether they ask for it or not; in the end you will have a graph that shows A) the four weeks they wanted, B) the six weeks you quoted and C) the eight weeks it actually took because they outsourced it; label this so that an idiot could understand it: "two week overrun due to outsourcing". Come to every meeting armed with figures, graphs, buzzwords. If you do this right you'll be amazed at how they accept whatever is on the graph, and how they see the graph itself not as a waste of time, but as "professional behavior".

Good luck, and let us know how it works out.

Breathe.

You sound like a Software Engineer.

A Project Manager is more focused on the status of the overall project and allocating resources in an effective way to ensure that milestones are being met and in proper time. They also remove roadblocks and help the project resources focus on their specific job functions.

Writing and maintaining design and technical documentation is an important part of being a software engineer and is appropriate for your role. Too much of a good thing can be bad though (See Analysis Paraylsis ).

He considers the design to be paramount, coding is "just writing the design down"

If the project manager considers the design documents to be paramount then he expects the documents as a deliverable in the process. It is not a wasted time on your part if he feels they are important enough to allocate 80% of your time to it.

it shouldn't take too long, and "all the code should be written before the hardware is ready".

This is wishful thinking and quite an antiquated Waterfall style view of how software development works. It invariably is never that clean no matter how much design and preparation that you devote. On that note however, you should have clear hardware specs and proper test environments and mock hardware simulations for your code to interact with but again, the real world is messy.

Project management is incredibly easy in a perfect world. The world is not perfect however no matter how much you wish it to be so making real project management incredibly difficult. This is why they are paid the big bucks.

(2) Doesn't understand the difference between a Central & Distributed Version control.

Why should he care? How does it affect the milestones? It doesn't.

3) Doesn't understand code, and wants to understand every bug and its proposed solution

His goal is for working software and yours should be too. He does not need to understand the code but he does need to understand the issues that are preventing working software. Once the two of you see eye to eye on this basic level then your mutual goal will help you work together more effectively.

(4) Believes verification should be done by developer, and validation by the Tester.

What is wrong with this sentiment? Testers in the quality assurance role should be concerned with validating features and requirements. Developers should make every effort to verify and test their work before it goes to testing.

I don't really like creating documents, I want to solve problems and write code.

If you would rather be a simple programmer then perhaps you should talk to your boss about this and see if there is a better role for you on the project. Somebody needs to write and maintain the technical documentation, so perhaps one of the other developers can help you with some of these tasks so you aren't spending 80% of your time writing documentation.

In my experience, creating design documents only helps to an extent, its never the solution to better or faster code.

This is mostly true... but only if all ten developers are spending 80% of their time writing technical documentation that nobody will ever read. This is an enormous management anti-pattern that I have lived in before. If you find that you are doing most of the documentation for the team then it hardly seems fair that you are denied the right to perform more coding work.

The fact of the matter is that the best technical documentation is the code itself.

I feel the boss doesn't really care about making better products, but only about being a good manager in the eyes of the management

I feel that he does care because the product is his ward and if projects and features are not completed and clients aren't happy then upper management will not care for him very much. The problem is that your perspective on the necessary quality improvements don't match with his, and upper management, and the clients perception of what they feel is important.

Try to understand what is truly important for the product, because while you can increase the efficiency of a process 3 fold, if you spend an entire week doing this then it is at the cost of another important feature that the client is demanding.

We all want to look good to the eyes of our superior. There is nothing wrong with that, it is human nature to be self serving. This is a fact of life.