We fired our top talent. Best decision we ever made

I'm not sure why you're being down voted, but this is a very reasonable counter point.

The purpose or brief should be at the top of every file, it should also evolve as class or implementation does. Arguable that it's really the only one that matters and can also come from no other tool or location.

I see a lot of red flags in this.

I suspect what happened here was Rick was the type of personality that defined himself by being the person who solved problems. He probably wasn't a genius, he was probably just senior and experienced.

He didn't want it to end up like this, I bet. I bet he didn't expect it. He didn't know how to say no, and even worse: no one knew that he should. Rick had no peers or management that could even faintly empathize. They didn't get that there was simply too much to do.

Rick's first and biggest mistake was long before his absurd outbursts: refusing to admit the project was too big before it was too late. Instead he imploded and started saying stupid and offensive things. He defined his identity by his ability to solve problems but no matter how much he tried, the problem seemed to get worse.

He got fired. He even deserved to be fired, I think. Because part of being the technical adult in the room is NOT letting it get that far out of control.

The ugly part is that it seems no real lessons have been leared by the org. Instead of recognizing the obvious lack of technical management, they're spreading the responsibility across the entire org. Intead of owning their business logic they called up vendors and sold it to them. Instead of broading the scope of the business with these added capabilities early on the entire business is now balanced on top of a pinhead of those few cases.

Everyone made terrible mistakes. And it seems like no one learned from them.

Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. I have files on an FTP server and I write PHP code.

But to explain:

> Author: completely optional, depends on what you are using, you aren't wrong.. since I'm old fashioned, if I were to hire some coder to help me maintain my programs, I'd like to know that he was in there, and I'd have no way of knowing.. again, probably not anyone's issue, but I'm old fashion.

> Status: Not all files are in use, but sometimes they are just leftover and may not be deleted, or sometimes, they might be used for testing purposes -- so Status can be changed to INACTIVE, TESTING PURPOSES ONLY, etc. Maybe the file is inactive because newer code was written, but this was kept as an archive? You never know.

> Purpose: always state the purpose of the code.. if it changes, than this should probably change. If it doesn't, than again: you must be doing your own thing.

> Notes: optional, this is just notes that might be necessary..... again.. Notes to myself: I have some code in there that is not currently being used and if I go into production, I probably won't need it so may as well delete it.

The Notes weren't supposed to be taken as a literal. This is just notes to anyone who reads the file.

Sure, there is a such thing as too much commenting, but no one wants to go through the code to figure out what it does. Leaving a little comment up top of every page, regardless of the simplicity or complications of the function, it is just nice to leave for anyone who has to go in there. It's a better form of organization. Imagine having to go in there 3 years later... would you remember what it does? The little statement up top might help you remember more quickly.

Dynamics of software development by him McCarthy published in 1995 covers this exact scenario in the "beware a guy in a room" rule

Not only that, but if they wound up throwing away so much supposedly unmaintainable code, then he wasn't the great developer they thought he was.