Flowcharts and pseudocode often have the same level of expressiveness, but differ in linearization. Pseudocode is linear (i.e. a sequence of lines with instructions), a flowchart is not. Therefore, flowcharts are a higher abstraction level, used before writing pseudocode or for documentation.
Flowcharts have, in my opinion, two strong advantages over pseudocode: Firstly, they are graphical. Many non-technical people have a strong fear of structured text, but not of graphical descriptions, so flowcharts will sit much nicer with them. Secondly, flowcharts are much better at expressing meta-considerations such as showing the main line of execution as opposed to branches.
Your questions in detail:
- For a really complicated problem, you would use flowcharts first, then pseudocode. Both are optional when you feel secure enough.
- Yes, pseudocode has the advantage of being mergeable with real code. Steve McConnell, for example, strongly recommends writing methods in pseudocode first and then leaving the pseudocode in the code as comments.
- I always felt that the need to draw a flowchart during design shows insufficient partition of your problem. Non-trivial flowcharts indicate convoluted logic, which should be avoided at great costs.
For this kind of work, I suggest you to learn about Maven which deals with dependency compatibility (among a lot of other things).
With Maven, you could for example use one of these two ways:
Either the "standard" way: by creating a Nexus repository which you will feed with a compiled jar of each version of your common package and to fully exploit maven/nexus the version(s) of JDBC you use. Each time you build your project from any commit, the versioned config file will be read and will use the good revision of your library "common".
(I say Nexus, but there are others software doing the same thing, I've also heard of one named Artifactory).
Or, you could make a more complicated script which, when you build your server or client project, go download the source of your library on your "common" repository and build it.
Maven may seems a bit overkill and is (in my opinion) a pain to learn alone, but it's handy, powerful, and is the professional standard in Java and works seamlessly with Eclipse.
As for the Maven usage, the Nexus way is (depending on your scripting skill) a bit heavier to init, but more standard, easy to scale with your project, and can be used for all your other future projects.
If you're working in a professional context, I strongly advise to look for a colleague knowing it to help you mavenize your project.
Best Answer
Writing pseudocode before coding is certainly better than just coding without planning, but it's far from being a best practice. Test-driven development is an improvement.
Even better is to analyze the problem domain and design solutions using techniques like user stories, use cases, CRC cards, diagramming, as espoused by methodologies such as Cleanroom, RUP, Lean, Kanban, Agile, etc.
Thoroughly understanding the nature of the problem and the components you use to implement the solution is the principle behind best practices.