First a little more on git branches. For proj2 I used quite a few branches and at one point I was in a cycle of trying things on different branches, frequently switching back and forth. What I noticed though is that I found myself committing changes to branches before they were fully baked a.k.a. before I would have committed them otherwise had I not been switching branches. What bothered me about that is that I am used to treating the commit as a sort of “sacred” step that you only do when absolutely certain that the code is fully baked and bug free. In my experience this notion is reinforced by both peers and management in professional environments. “So and so broke the build” was a distinction no one wanted to be tagged with. But of course something else very different with git is the distributed architecture w.r.t. the old centralized SCCSs. After all just committing a change (in git) doesn’t necessarily make it available to anyone else. Interesting.
Well I am reasonably pleased with my performance on the first exam. My exam score is much better than my quiz score average. What I’ve figured out is that I am well prepared and I know the material. But it’s some rusty test taking skills that cause me to lose points. For instance on the exam I lost almost zero points due to lack of knowledge of the material. Rather, it was my inability to go back over the test w/out a biased notion that what I had first written down was correct! I suspect that this is largely due to the fact that, while I’ve been writing code for a long time I haven’t had to produce correct code without the “aid” of a compiler and run time execution to test it! But, I’m gettin the hang of it.
I thought I’d mention that I had a bit of experience with something similar to pair programming at one particular place of employment in the 90s. We called it peer review. Late in the development cycle we would go through a few of phases called “feature freeze”, “critical freeze”, etc. as time grew closer to the release date. During the freeze phases all remaining code mods (only critical bug fixes) were to be peer reviewed to help ensure no new bugs were introduced so late in the development cycle. This literally involved grabbing one of your peers and having them sit down next to you and go over your mods and make sure they looked good to at least another set of eyeballs. As I recall it worked very well. So when I first heard of pair programming I immediately was reminded of that experience as being a good thing.
Lastly I wanted to mention that I’ve actually been using the CPPUnit test harness for many years. I remembered that I first read about it in the now defunct C/C++ Users Journal and sure enough when I searched there it was: http://www.objectmentor.com/resources/articles/TDDinC.pdf . I liked the idea of building the unit tests as you go along side of your code. I’ve used it on almost every project I’ve worked on since. So, I was delighted when I saw the requirement that we use CPPUnit in our projects.