I think I have to agree with you. The fact that Rick was allowed to be turned from a Dr. Jekyll to a Mr. Hyde is kind of the company's fault. No one stepped in to hold Rick accountable during meetings?

While I no longer work there, my first job with some programming had me training to understand the code, what it was about, and even how to write it.

To this day, I still use this method so I don't get lost or bored in my code.

These are the lines I actually use along with commenting my own code just in case I have to return back to it weeks or months or even years later, I don't have to try and trace every step back to a particular code.

  // AUTHOR: MG
  // FILENAME: functions.php 
  // STATUS: ACTIVE
  // PURPOSE: All of the functions for this application (app name)
  // NOTES: There are several unused functions in this file that are commented out but once in production
  // They can be deleted as we likely will not be needing them at all.

Those 5 lines have saved me a lot of time. While I don't include the "author" line since it just me writing the code, if there are tons of hands in there, you should know EVERY SINGLE author as well as when code gets commented, it should contain the initials upfront, such as // mg: this does this and this does that. If I know multiple files touch.. I also add: "ASSOCIATIONS:" and list all files that call this one.

Using this method, I've been able to complete a bunch of projects much quicker because any time I start to forget: what am I doing? what does this code do? am I on the right track? I can look right at the beginning of a file and know the answer.

I'm not saying that a boss or supervisor has to be a micromanager, but meetings are necessary to understand where everyone is at. Leaving a programmer to do his own thing means that he really is doing his own thing and is more likely to get lost in the code. I'd say more like he wasn't a genius but thought he could do it alone.. and sometimes, it is nice to have someone step in and tell you: "Hey where we at? What can we do to speed this up?" or even provide their own insight... I can't tell you how many times I've talked with my spouse about an issue.. and she's suggested, "Why don't you just do this?" and it has saved me hours of time just because of someone not in the code is able to see another solution.