Just a followup - over the years I have tried many different ways of organising files - non of them are good.
What I currently do (or am tending towards) is the following:
a) All modules that I think I might reuse are put in the same directory (called Dropbox/elib) with hopefully meaningful module names.
The advantage of this is I can grep for things in this directory and easily find things.
The Dropbox bit means my files are synced across all the machines I use - so for shared code there is one version (the latest) with a unique name on all machines.
It’s not even in GIT - I don’t want all old versions of the code just the latest and I’ll change the name if I make significant changes to the code - (and I’m not collaborating with anybody here - for collaborative code I do use GIT - but for private projects I don’t care about branches and saving old versions - just the latest is fine)
(I should add that I’m old-school - I learned to program before revision control systems where invented - so we developed strategies based on file naming that were useful - these strategies are a lot simpler than things like GIT and are fine for personal projects - but not for big collaborative projects)
b) All projects go into a sub-directory of Dropbox/experiments with a meaningful name
c) Inside a project directory (say Dropbox/experiments/transluder) local modules are just stored anywhere - but modules using the shared code in lib I just add as symbolic links.
This has a few advantages - my ls command colors symbolic links so I can see they are shared. The editor always edits the master version (in lib) - all experiments using the shared library get to see the same version of the code.
What I actually hate is having multiple versions of a file with the same name in different directories. These files endup with different sizes and modification dates. Some go back 30 years and all are slightly different.
I also hate the idea that files with the same name (in different directories) can have different contents. It’s ok for a file with a unique name in a single directory to have time varying content - I’m usually only interested in the latest version.
Before GIT (and friends) I used to name files with names like lib_this_vsn1 lib_this_vsn2
etc. bumping the version when appropriate. This was great - all the old versions were frozen and we knew that the greatest vsn could change without warning. This was how erlang was developed 
- there was no GIT @rvirding and I worked on a module until we got fed uo and then mailed the latest version to each other.
GIT etc hides this so we just say lib_this - the problem here is this fails the “telephone test” - ie if we were to tell somebody "code code is in the file XYZ’ two people could view the file at the same time (both see it is called XYZ) but they are looking at a different version of the code and are not aware of this fact. This has happened to me so many times since files get them selves detached from their revision control systems (for example by send in mails) and is large source of errors.
Actually there this is a symptom of a much deeper problem - but there is not room here to explain this (short version - the problem lies in editors, they do not record where the data in the file came from in the first place)
