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

31–40 of 137 posts

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

#31

Post by invisible »

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.

My feeling was that the spec they wrote and sold was "very hard." Rick neglected to push back (or did and was told too bad) and then the entire project was mismanaged.

Maybe Rick was an asshole, but this post kind of blows my mind. I'm making some assumptions here but "two years" of delay isn't something one person causes (unless they're enabled to).

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

#32

Post by gregmac »

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…

> Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school.

You would do well to learn source control system (which these days basically means git).

Leaving aside the team/collaboration part, once you learn it, it's so incredibly freeing. I cannot understate this enough.

You can make changes to the code, and then go back with one operation (discard changes). You can work on an experimental idea (in a branch) for a few days/hours, then switch back to your main code to fix an important bug, go back and finish your experimental branch eventually, and merge everything together -- often with nearly zero effort. If you're supporting multiple release versions at once, you can fix a bug in one and often easily apply it to all other versions.

Ever have a situation where something just stops working, but you're not sure when other than in worked four months ago? You can arbitrarily check out any old version and test, and even - in a single operation - undo that change from the current version of code.

Can you do all this without source control (or with copies named by date)? Sure, but it's kind of like the difference between fetching water from a well using a hand pump and bucket vs having running water and being able to open a tap. Before you have running water, it's just life, and it's not that big a deal to fetch water, really. Once you have it, you could never imagine having to live life that way.

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

#33

Post by munin »

shoo wrote: post #25
alistproducer2 wrote: post #7

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.

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

They did as soon as they had someone to blame, though.

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

#34

Post by mattbgates »

sverhagen wrote: post #21
mattbgates wrote: post #16

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…

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

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

#35

Post by Frondo »

KirinDave wrote: post #14

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…

Eh, I've joined 3 or 4 projects where there was a "genius" behind it.

They liked being in control, and to a one they all talked about being irreplaceable.

I don't know Rick, of course, and can't speculate on what's going on in his head, but he certainly seems like the geniuses on the projects I and others ended up rescuing from their own respective geniuses.

I think everyone's quick to pile on the author, for some reason, but the Rick side of the story just rings so many bells for failing projects I've joined (or, later on, took over and reimplemented by myself).

I'm no genius, either, just old enough to know a little tiny bit better.

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

#36

Post by g051051 »

invisible wrote: post #31
g051051 wrote: post #20

Earlier quoted context omitted.

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.

My feeling was that the spec they wrote and sold was "very hard." Rick neglected to push back (or did and was told too bad) and then the entire project was mismanaged. Maybe Rick was an asshole, but this post kind of blows my mind. I'm making some assumptions here but "two years" of delay isn't something one person causes (unless they're enabled to).

Exactly...what was going on for 2 years that they could slam out a replacement in just a few months?

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

#37

Post by KirinDave »

Frondo wrote: post #35
KirinDave wrote: post #14

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…

Eh, I've joined 3 or 4 projects where there was a "genius" behind it. They liked being in control, and to a one they all talked about being irreplaceable. I don't know Rick, of course, and can't speculate on what's going on in his head, but he certainly seems like the geniuses on the projects I and others ended up rescuing from their own respective geniuses. I think everyone's quick to pile on the author, for some re…

Please don't take my analysis as a way to absolve Rick. He's the worst type.

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

#38

Post by lucio »

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.

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 removed over 30% of Rick’s work

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 and beautiful code). If not managed correctly, 10x programmers will choose the most complex, self-configurable solution where a hard-coded workflow will do.

TL;DR: It seems a manager failure. Top talent needs top management in order to focus great creativity in the narrow path of productivity clients will pay for.

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

#39

Post by mattbgates »

gregmac wrote: post #32
mattbgates wrote: post #16

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…

> Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. You would do well to learn source control system (which these days basically means git). Leaving aside the team/collaboration part, once you learn it, it's so incredibly freeing. I cannot understate this enough. You can make changes to the code, and then go back with one operation (discard changes). You can work on an experiment…

I do know what "source control" is but even when I wasn't working for myself, my boss made me still add this stuff, despite knowing at the end, upon saving, it would ask what changes were made.

We used something called "Source Safe" from Microsoft.

As for what's in the Notes and deleting it upon live production... that is the old stuff... in case the new stuff stopped working for whatever reason.

I guess we all have our own methods of doing things. Fortunately, I've not had major issues, though everything is backed up to it a server upon my completion of work for the day.

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

#40

Post by Clubber »

>Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.

It's both. Don't fall into the trap that collaboration, tenacity and mutual respect will compensate for lack of talent. You still need to find talented people, just don't hire assholes or turn them into assholes.

Post reply on HN