Re:Robinhood lays off 23% of staff
by bpodgursky on Tuesday August 02, 2022 @11:49PM
(#32327441)
I understand this as theoretical possibility, and it could lead you astray if you're trying to tell a 40% developer from a 60% developer... but in practice I have never met a superstar IC who doesn't also ship a ton of code (even while they help out others). If you fire the 10% of ICs who push the least code, to within a rounding error you're extremely unlikely to regret it.
Re:Robinhood lays off 23% of staff
by Foobar8568 on Wednesday August 03, 2022 @01:10AM
(#32327879)
Your best engineers are facilitators, not coding monkeys.
Re:Robinhood lays off 23% of staff
by manigandham on Wednesday August 03, 2022 @02:15AM
(#32328228)
Those are not engineers then, they're managers.
It's strange to see this confusion when it comes to software. Any other discipline and you wouldn't say engineers that don't do any engineering are the best engineers.
They are still ICs, not people managers.
Re:Robinhood lays off 23% of staff
by manigandham on Wednesday August 03, 2022 @03:00AM
(#32328505)
Project management != people management.
Either way, IC means primarily a producer of work product, not a manager.
Re:Robinhood lays off 23% of staff
by Foobar8568 on Wednesday August 03, 2022 @03:18AM
(#32328605)
Project management!= manager. And your PM/PO whatever won't coach your junior devs...
That’s usually what poor engineers tell themselves
Re:Robinhood lays off 23% of staff
by bpodgursky on Wednesday August 03, 2022 @01:12AM
(#32327884)
Your best engineers are both.
Re:Robinhood lays off 23% of staff
by Foobar8568 on Wednesday August 03, 2022 @01:27AM
(#32327965)
You can't do both unless you are one in your team.
The more people, the less code you'll do.
Software engineering goals is to solve human problems, you can't escape human relation, which eventually means facilitating stuff.
Re:Robinhood lays off 23% of staff
by sirclueless on Wednesday August 03, 2022 @12:54AM
(#32327804)
That may be true but people here aren't talking about firing the bottom 10% of ICs, they're talking about firing "50% of Google".
Some of the very best engineers write the fewest lines of code, often making fewer yet better abstractions that fulfill more business use cases more simply. They might also help others write less code.
Some of the most prolific coders are great. And some are terrible. The challenge is discerning the two. Coaching a prolific yet bad coder to slow down can be as challenging as coaching up a slower / not yet confident coder. And the slower coder will do vastly less damage in the interim.