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

81–90 of 137 posts

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

#81

Post by imron »

hkjayakumar wrote: post #78

The author elaborates a bit more on how management unsuccessfully tried to reach out to Rick, resulting in their departure before Rick's in response to a comment[1]. This post is obviously just one side of the story, so take it with a grain of salt I guess. [1] https://medium.com/@peachpie/thanks-for-the-insightful-respo...

The key point being:

"He never should have been allowed to take on so much. If it gives comfort to anyone else reading this, the manager went first because ultimately management bears responsibility, always.

I was brought onto the team after that, as a hail-mary pass."

The original manager screwed up to let Rick get to that point, and once at that point it was impossible to manage him, hence him getting fired.

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

#83

Post by [deleted] »

6nf wrote: post #51
cpncrunch wrote: post #43

Earlier quoted context omitted.

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.

The author is not to blame for the problem of course - since the problem existed before his arrival. The author made the problem worse by implementing the wrong solution. The company was lucky to survive this misstep, and poor Rick was forced to work insane hours just to end up being fired anyway. Not a good outcome for anyone. The company looks bad for mistreating a seriously committed employee. Rick looks bad becau…

[deleted]

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

#84

Post by mythrwy »

projektir wrote: post #76
lucio wrote: post #38

Earlier quoted context omitted.

If he had the respect of his coworkers, I'm guessing "Rick" was really a 10x programmer, BADLY MANAGED. You need somebody else who understand the project objectives and can put a limit to the development of "configurable" options. >Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This rem…

> That's a failure of the manager, not the programmer. The good programmers, the ones who enjoy their work, will choose a complicated but beautiful path, will choose to make a configurable workflow whose configuration is itself configurable in LISP. It's the manager job to know that the workflow can be hard-coded and then avoid complexity by the love of complexity (good programmers love complexity solved by intricate…

The buck stops with the manager. Every time. Only a poor carpenter blames his tools and people are a managers tools.

If a carpenter doesn't pay attention and a sharp saw cuts their hand off or ruins an expensive piece of wood maybe they need training in how to run saws. Or perhaps they just need less powerful saws until they get more experience.

Management is a lot more than going to meetings and ordering people around. The ability to successfully staff and orchestrate a project is no small skill and one can't just jump in and expect success. Lot of people think they can do it, but there are very few really good managers in my experience. Most are hacks who can't actually do the job and don't even understand what it entails. As evidenced by the article.

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

#86

Post by valuearb »

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.

I have been coding for almost 40 years and always been big on documenting code, but the problem is that code changes and documentation doesn’t always keep up.

Given modern tools I’ve come to the conclusion that documenting overall purpose and specific edge cases is more than enough. For example, the file header should describe its purpose, and anything in the actual code that’s not obvious should be commented. No more boilerplate function or file comment header. Git tells me who wrote each line of code, I know the name of the funcs and files, and I can see the inputs/outputs for every func with my own two eyes.

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

#87

Post by valuearb »

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

I also think it's kind of silly to criticize a solo developer for not documenting. Has anyone seen a mid-sized team that doesn't explicitly delegate or make documentation a priority? Now you expect a solo person to document?

I expect every professional developer to do at least the minimum necessary level of documenting, be they solo, small team, big team, startup, corporate, etc, etc.

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

#88

Post by zzalpha »

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…

Ah, I see!

So from one article and no actual evidence or information, a random Hacker News subscriber managed to determine that a story about a bad dev written by an insider on the project was actually about a poor, amazing, faultless dev who worked at the whim of Bad Management.

Because, as we all know, Management Bad, Dev Good.

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

#89

Post by zzalpha »

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

I also think it's kind of silly to criticize a solo developer for not documenting. Has anyone seen a mid-sized team that doesn't explicitly delegate or make documentation a priority? Now you expect a solo person to document?

No developer is a solo developer. At a bare minimum, Present You is working with Future You. And Future You would appreciate it if Present You documented your work.

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

#90

Post by skinnymuch »

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.

You said initially companies have their tools and you don't. Later you went on about simply using ftp and coding php. It sure seems like you don't use version control. At least not at a level that it should be used at in this day and age.
Post reply on HN