Here is a course I'd recommend to get a better understanding how how a version control system works: https://www.udacity.com/course/viewer#!/c-ud775/l-2980038599
. It's not terribly difficult to understand from a high level. Basically, software developers are working on the same application on different machines and at different times and locations. In a perfect world, each would have their own little module they are responsible for and no one else would ever touch their code.
Of course, this isn't the case, development is a collaborative, often messy process with many different eyes and hands touching the same source and at different times. Thus one needs what is called a version control system to sort out who has done what and when and also to create living history so that one can rewind the clock to earlier periods in the project's history.
Often one can look at commits as a metric of developer productivity telling you in a transparent log when, how often and what a developer has done. Git is a decentralized software system to sort all of this out. Github is a website that allows people to store and audit their code online and is free to use for open source projects. There are many types of VCS and lots of philosophy on how to use them and what is best for a particular type of project. I'd recommend looking at this wiki: http://en.wikipedia.org/wiki/Revision_control
for the terminology that is commonly used and also this wiki for list of different VCS -> http://en.wikipedia.org/wiki/List_of_revision_control_software
I hope that helps
Any suggestions of what other holders like myself can use to help to gauge what coder is doing. I know this is a tough question, I am just looking for some guidelines.
Without having knowledge about the language they are coding in or the fundamentals covering the problems they are trying to solve, this is tough. Generally you can look at documentation associated with commits, code comments, check style and format of the code via some validator like pylint. Also you can ask questions about quality control and testing. For example, where are the unit tests. How did you determine that once merged this code wouldn't break the system? Peer review is also a valid way of determining quality. There are development systems like behavior driven development and methodologies like Scrum that help make the process smoother and more auditable to outside parties.
The reality is that the environment in which the code is written and the project management has as much to do with the end result as the skill of the developer. Bad processes can slow or destroy progress and force bad architecture to be maintained. Also there is a broader meta question of what do we want this program to work with and on? The decisions made there can dramatically impact speed quality, security and usability. Generally the person responsible for those decisions has a role like chief software architect.