Programming: Putting all of the Pieces together (Part 1)

It struck me the other day as I attempted to navigate my project's git log to review code that my team had pushed into the repository, something was missing.  It's taken a long time to pull myself out of the student programmer headspace and towards a full fledged developer whose code is sacred and must retain its history.

A Little History
I didn't get started with computers until around 2000.  Of course we had one at home, but my father is a programmer and for him at the end of a long day working for a bank he didn't want or need a computer at home.  Until 1994 we had a little black and white dos box.  That was replaced by a 386 with windows 3.1 until 1999 when I would get my own computer for college.

Fast forward through 5 years of school 2 spent as pre-med and 3 as computer science and enter my first programming job at the UF Computing Helpdesk.  It was a part time job with-in a part time job.  When items were finished they went to production and that was that.

From there I went to work at Smathers Libraries a Microsoft shop.  We used Visual Studio and Visual Source Safe at first.  For those who are rabid against MS, set aside your anger. Visual Studio is quite nice even though it is proprietary.  Visual Source Safe on the other hand, absolutely abysmal.  It would claim files were locked by one user only to find that person didn't have the file locked and could not unlock it.  It would over write newer files with older files when a person saved.  In summary, it stunk.

So we switched to the next best thing, in our uneducated opinions, versioned out file folders.  Basically a by hand version control system.  We were pair programming a rather large project so every morning the code would get copied to the file share and appended with the date and prefix AM.  In the afternoon the same would occur with the prefix PM.  It worked fairly well, the file share was backed up on tape and lived on a SAN that had a redundant system across campus.  Sure we had to navigate folders to find old versions of code, but we hardly ever looked back.  Who would need to do that?

Back to Today
Since VIVO, I've been immersed in SVN, Mercurial, CVS, Bazaar and Git.  I've learned the ins and outs of my old pal from undergrad, Eclipse.  I've used various bug and feature tracking systems; SourceForge, Jira, Launchpad, and FusionForge.  Its all coming together, the lifecycle that is software development.  The code is simply the result of all the pieces falling into place and without the right pieces, the code usually suffers.

Back to my current delima.  I have very junior programmers.  They come from a mixture of environments and educational levels, and for all of them I'm deeply concerned with what they took away from those experiences.  For example, perhaps its the sum of all of my experiences or perhaps its the first school project that nearly missed a deadline due to a hard coded value but I strive not to do these things.  I found, when helping a masters student fix a table filtering issue, hard coded drop down lists for items that are stored in the database.  The breakage was due to spelling differences between the database and the dropdownlist, obviously.  Their code is scary and the worst part I am putting my and the departments reputation behind it.

So how do I help them learn and avoid accepting bad code.  My brain slowly starts up, the hamster rising from his nap, and I think "Review their code".  So I open the code and before I begin to browse the first spark hits, use the gitg explorer so you can review what they are changing.  "Duh! How can I help them improve if I don't know who committed the error."  Now my hamster is not yet up to speed and when we finally got up to speed I processed that something was missing.  Why am I doing this code review by hand?  I have standards documents and with VIVO I've used code coverage reports and unit tests and acceptance tests.  How do I put this all together?