Live data from Hacker News

We fired our top talent. Best decision we ever made

medium.freecodecamp.org

21–30 of 137 posts

Re: We fired our top talent. Best decision we ever made

#21
post #8

Earlier quoted context omitted.

> 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 (a…

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 anyo…

"Old school"? I think it's in most cases irresponsible not to use version control. Sorry to say, but it's "amateur hour". No better than "Rick".

I agree with one of the parents that "Purpose" is probably the most useful, but even there: at that level the code should be largely self-documenting.

Re: We fired our top talent. Best decision we ever made

#22
post #19

Earlier quoted context omitted.

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 anyo…

rcs has been around ~40 years. you're not old school. you're sloppy.

Well, I'm glad you don't have to go into my code to see that sloppy tabbed mess full of comments and code :)

Re: We fired our top talent. Best decision we ever made

#25

Rick was not managed - at all. Rick became a monster because no one at the management layer was doing their job. If you're letting coders write custom tools instead of procuring where possible, that's management's fault. The list of mismanagement goes on and on. Sure Rick was a douchebag. Anyone who has spent any time in a cs program has met a potential Rick. The fact that you fostered one while he almost blew up you…

There also seems to be a vacuum of project management.

No one had the hard discussions with clients to reduce scope and cut high effort/low reward features?

They knew he was working 80 hour weeks and didn't take steps to address that early.

Re: We fired our top talent. Best decision we ever made

#26
The author has the audacity to lay 100% of the blame at the feet of his "genius". Sadly, the author will run continually into new sets of problems again and again at his company and each time find a new scapegoat. This is because 1) he cannot recognize that he is the problem and 2) attacks those who has scapegoated in public.

Until the author matures, employees would be wise to run in the opposite direction. If they don't the next article will be about one of them.

Re: We fired our top talent. Best decision we ever made

#28
This looks like gross mismanagement. Gross mismanagement of client expectation, gross mismanagement of product scope, gross mismanagement of feature/engineering processes/schedule, lack of leadership, and worst of all, gross mismanagement of talent. It sounds like management has no or very little technical background. Didn't understand how to build the product or translate requested features into feasible functionality. And simply thrust the whole problem onto a single senior developer. The guy while talented was overwork and exhausted. I would turn into a Mr. Hyde too if I have to work seven-day weeks, twelve hours a day.

Re: We fired our top talent. Best decision we ever made

#29

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 becaus…

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…

Why don't you use source control instead. Don't say who you are in the comments, that's what "blame" is for. Don't comment code, delete it, it won't be lost since you have a history. Make a branch for your experiments if you have to. The state of your work should be apparent in the bugtracker.

Code comments are code comments. If you use comments to help with your development process, there is probably some work to do with your toolchain. Good source control and a bugtracker are a must.

Post reply on HN