We fired our top talent. Best decision we ever made

TBH, I read this as: we mismanaged the project for months (years?), reduced scope creep by negotiating with the client, and finally implemented what should have been the version 1.0 solution while shifting the blame entirely on the loner dev who worked himself into a corner trying to catch up to our sales department's untenable promises.

Everyone created the problem, the dev was an easy target to eat the blame because of his ego.

"We could not build a hotel, so we bought new hammers and built a great dog house instead."

Pair-programming greatly reduces the risk of this situation arising.

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.

> AUTHOR: MG

This is already in your commit history, so why hardcode it into the source?

> FILENAME: functions.php

This is obvious because you just opened the file. So again, why even put it there? When the file gets renamed the documentation is no longer correct? These things are also hard to refactor.

> STATUS: ACTIVE

Every part of the code is always active...

> PURPOSE: All of the functions for this application (app name)

Okay, probably the most useful one here. But what if we're refactoring the code and the purpose changes? Or if someone adds a few functions and the documentation no longer covers the purpose?

> 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.

Very dangerous, again because the source might change while the documentation doesn't. But why even write "they can be deleted"? Why not just delete them? That's what version control is for.

Makes you wonder why the company would consider him their "top talent".