Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We fired our top talent. Best decision we ever made

medium.freecodecamp.org

Post reply on HN
Print view View original

41–50 of 137 posts

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

#41

Post by sverhagen »

mattbgates wrote: post #34
sverhagen wrote: post #21

Earlier quoted context omitted.

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

I never said I didn't have version control. To assume "at the code level it should be largely self-documenting" is to be a Rick. Comments are there to help everyone, including non-programmers understand what is going on.

What am I to make from: "while I know companies use tools to do their thing... I don't", if not that you're not using a version control tool?

It's not "genius behavior", but well accepted from people like Uncle Bob, that documentation should be in the names of small and focused functions, methods or classes, not in comments.

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

#42

Post by Clubber »

g051051 wrote: post #20
wakeywakeywakey wrote: post #2

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…

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.

Sounds like they graded him on feature completion rather than how he implemented the features. It's a one sided story though. I've seen projects fail due to constantly "rearranging the furniture."

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

#43

Post by cpncrunch »

davmar wrote: post #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…

Well, I think the "genius" deserves most of the blame. The company obviously shouldn't have allowed this guy to waste 2 years writing crap, but I don't think it's fair to say that the author of this article is "the problem". That's like blaming someone for hiring an incompetent builder to build their house.

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

#44

Post by md224 »

mattbgates wrote: post #16
Avalaxy wrote: 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…

I'm an old school surgeon... I like to operate without using anesthetics or sterilizing my tools.

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

#45

Post by Clubber »

davmar wrote: post #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…

In all fairness, it sounds like the author took over the project after it was already 2 years late.

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

#46

Post by hmwhy »

I think another issue that may be worth mentioning is that a lot of the articles in the freeCodeCamp publication are written specifically to appeal to people who are not (yet) very skilled.

At least in this particular case, the combination of the red flags already mentioned by many together with the demographics of the target audience seems like a dangerous combination that promotes stigmatisation of "talents" and the idea of "if you can't become it or work with it, kill it".

I may be reading between the lines a bit too much, but the article appears to be exceedingly popular by the freeCodeCamp publication standards, and that, to me, is very unsettling for a story that I think is effectively "management turned mismanagement into a heroic triumph".

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

#47

Post by steego »

mattbgates wrote: post #16
Avalaxy wrote: 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…

You need to seriously stop wasting time talking about this on HN and learn you some basic git.

https://try.github.io/

It's not hard. It's not like you're computer illiterate and don't know how to program.

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

#48

Post by wdewind »

Everyone is commenting on the mismanagement angle here, which is very real, but I think it's also important to point out that the author is simply wrong about "Rick" being a genius if the descriptions of his behavior and work product are accurate. I think there's a huge myth about solitary geniuses who are assholes. I've yet to meet someone I consider really genius who is also a toxic asshole. Maybe occasionally you run into geniuses who are a little shy or socially awkward, but by and large the defining factors of the true geniuses I've worked with have always been a desire to share with the team, improve everyone around them and contribute deeply to the product. Their code is maintainable and other engineers totally get it and when they don't the genius is there to walk them through it, taking notes on how they can make it easier to understand next time. They hate the idea of being a dependency/SPOF, and they are extremely accountable for very real and obvious progress.

I've also worked with people genuinely like "Rick" from the article. It usually takes about a week to find out that they don't actually write any code or contribute to the team in any meaningful way besides making noise. People who are that wrapped up in their own ego cannot make meaningful contributions to their teams.

It lends more weight to the idea that there was a ton of mismanagement going on at this company that beyond the bullshit described in the article, the author still considers "Rick" to be a genius.

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

#49

Post by perpetualcrayon »

If I were in charge of the people on the project I would ask for the paper trail to see what kind of methodology was being used to make progress.

I would probably end up finding that there was none (or only a bunch of CYA paper trails), and fire everyone who was involved in that project.

EDIT: I once was recruiting for a project I was working on, and one of the candidates during a phone interview bragged about a poorly managed project they were on that "wasn't their fault". I didn't address it, but that's where they were sorely mistaken. Not doing anything when you know there's a problem (even if you don't know what the problem is) is not a valid strategy IMO.

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

#50

Post by cpncrunch »

paxys wrote: post #24

From the way they described the developer and his work habits, it doesn't look like they have a good idea of what "top talent" means. Probably one of those places where you have to look busy and act smart to get promoted vs. actually producing results.

Exactly. There is nothing inherently wrong with a single developer building an entire product, and I know a lot of very good "10x" developers who work mostly on their own and build great products.

The reality is that there really are a lot of 10x developers out there, but there are also 0.1x developers like this guy, who actively sabotage projects.

Post reply on HN