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

Today I've made the difficult decision to reduce the size of Coinbase by ~14%

twitter.com

Post reply on HN
Print view View original

831–840 of 842 posts

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#831

Post by matrix87 »

kelnos wrote: post #515

> Leaders will own much more, with as many as 15+ direct reports. [...] Every leader at Coinbase must also be a strong and active individual contributor. Managers should be like player-coaches, getting their hands dirty alongside their teams. Oof. So not only are they giving their remaining managers more reports, but those managers will be expected to do lots of other, non-management work. Sure, nothing can go wrong…

I think the point is to push people out primarily.

This gives them a narrative for doing that by asking for something which isn't doable. Then middle management applies the expectation unevenly to people below them based off of political favor.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#832

Post by twosdai »

dahart wrote: post #728
twosdai wrote: post #686

Earlier quoted context omitted.

It is possible to move most of that discussion to required but intentional async communication.

Yes, of course, and I do use both. There are underlying assumptions in your suggestion that it’s one or the other, and that async is somehow better. It’s worth considering whether those are always true, and trying to put a finger on the specific tradeoffs, because there are both advantages and disadvantages. I’m a believer in using the right tool for the job (and also understanding clearly what the job really is). IM…

Good callout on the underlying assumption. I agree.

And I additonally agree that people will gravitate toward comfort over the right choice.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#833

Post by aprilthird2021 »

hvb2 wrote: post #580
aprilthird2021 wrote: post #566

Earlier quoted context omitted.

Also, why use the analogy of player-coaches? How many successful player-coaches are there in the big leagues? There's a reason it's very uncommon ...

This ain't about sports. In most sports you've retired by the age of 40 and most coaches are older than that. I would say that's the reason it's common in sports, but that's the exception not the rule

Then why did they use the player-coach analogy if it's not about sports...

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#834

Post by aprilthird2021 »

adamtaylor_13 wrote: post #807
aprilthird2021 wrote: post #562

Earlier quoted context omitted.

Give an example. I have an example in my line of work. Full service rewrite in a new language. Would have taken forever without AI. AI makes it easier, faster. The service has better throughput, uses less machines. Having a complete full test harness that allows us to ensure we are meeting all the functionality of the previous service is key. AND we are keeping the old service on standby because we know we don't know…

From another comment above: > Our projects are closed source due to our clients owning the code, but I can offer anecdote. We have a client whose business operates on 2-3 very niche SaaS applications in the veterinary/animal medicine space. In a span of about 6 months, we completely ripped out 2 of those 3 and are working on replacing the 3rd one right now. We've done this with a single senior engineer working with t…

Yeah that validates my experience. It's best / mostly preferable for ground up rewrites and greenfield work.

I worry we haven't had to maintain vibecoded applications much and have no idea how difficult they will be to debug (or not).

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#835

Post by aprilthird2021 »

pron wrote: post #654
aprilthird2021 wrote: post #562

Earlier quoted context omitted.

Give an example. I have an example in my line of work. Full service rewrite in a new language. Would have taken forever without AI. AI makes it easier, faster. The service has better throughput, uses less machines. Having a complete full test harness that allows us to ensure we are meeting all the functionality of the previous service is key. AND we are keeping the old service on standby because we know we don't know…

If you carefully review the code then you're not doing what Armstrong was talking about. If you're not reviewing the code, then you don't really know what it is that the AI built. Of course it passes tests; that's not the problem. The problem is that the code is complicated and obtuse, even if it doesn't seem that way on the surface, and after some rounds of evolution, the agents are no longer able to evolve or maint…

I was pretty clear that we did not review all the code, and we have kept the original service on standby exactly because we are aware code is complicated and could have obscure failure modes while passing our whole test suite.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#836

Post by edmiller287 »

dahart wrote: post #672
siren2026 wrote: post #561

Earlier quoted context omitted.

Or maybe we should go back to what it was before Google and big $$$ tech decided that if you were a "manager" you shouldn't contribute technically. Being a manager now means a bunch of busy work talking to other managers and weekly 1:1s. There is a ton that has been written about the managerial class. Producing nothing, but for sure making themselves look self-important. Before that the manager was essentially the be…

> We don't need weekly 1:1s to check on feelings. As a manager that does weekly 1:1s, I agree with that statement. But I do need 1:1s to check on progress, uncover blockers that people haven’t surfaced on their own, make continuous small decisions, offer support, assess performance, collect status information for my manager, and last but not least give employees the opportunity to share feelings frequently. They do,…

> designing clever code and over-engineering things that weren’t needed

I agree with keeping sync'd with your devs but these sorts of behaviours should be caught and corrected in code review

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#837

Post by dahart »

edmiller287 wrote: post #836
dahart wrote: post #672

Earlier quoted context omitted.

> We don't need weekly 1:1s to check on feelings. As a manager that does weekly 1:1s, I agree with that statement. But I do need 1:1s to check on progress, uncover blockers that people haven’t surfaced on their own, make continuous small decisions, offer support, assess performance, collect status information for my manager, and last but not least give employees the opportunity to share feelings frequently. They do,…

> designing clever code and over-engineering things that weren’t needed I agree with keeping sync'd with your devs but these sorts of behaviours should be caught and corrected in code review

Absolutely agree!

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#838

Post by edmiller287 »

etruong42 wrote: post #764
shepardrtc wrote: post #734

Earlier quoted context omitted.

> uncover blockers that people haven’t surfaced on their own I constantly reiterate to people, whether they're reporting to me or not, that they need to speak up when there's a blocker. I feel its a very telling skill of engineers whether or not they can communicate issues in an effective manner urgently and figure out the best course of action to unblock. I've heard tales of 300k/yr engineers that just sit there and…

> I've heard tales of 300k/yr engineers that just sit there and wait for a manager to ask if they're blocked, or just sit there until they're told what to do. This is widely presumed to reflect reality within a 1-2 degrees of separation from myself as well as from many of the people I speak to. Part of the problem is that there is always plausible deniability. Like the adage of how unwise it is to fire custodians jus…

> Like the adage of how unwise it is to fire custodians just because you never see a mess and therefore you never actually see the custodians do anything, it may be "unwise" to lose the presence of these 300k/yr engineers just because they somehow actually keep things going smoothly.

so you should keep people on pay-roll because they "might actually be doing something if you look hard enough" ...? don't think so

> People who experienced these cultures may be waiting for private conversations

the error is the "waiting" - if you have a problem it is your responsibility to do something about it

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#839

Post by mdavid626 »

adamtaylor_13 wrote: post #775
mdavid626 wrote: post #555

Earlier quoted context omitted.

Shipping garbage.

We have zero Honeybadger errors, performance is acceptable for all our routes in the application, and all of our key stakeholders are ecstatic about what we've built. Is there some other metric I should be measuring our code by?

What about the actual users?

If this works for you, go ahead, I can't stop you.

But this is not software craftsmanship, or even software engineering. Don't act like it is.

Re: Today I've made the difficult decision to reduce the size of Coinbase by ~14%

#840

Post by dahart »

edmiller287 wrote: post #838
etruong42 wrote: post #764

Earlier quoted context omitted.

> I've heard tales of 300k/yr engineers that just sit there and wait for a manager to ask if they're blocked, or just sit there until they're told what to do. This is widely presumed to reflect reality within a 1-2 degrees of separation from myself as well as from many of the people I speak to. Part of the problem is that there is always plausible deniability. Like the adage of how unwise it is to fire custodians jus…

> Like the adage of how unwise it is to fire custodians just because you never see a mess and therefore you never actually see the custodians do anything, it may be "unwise" to lose the presence of these 300k/yr engineers just because they somehow actually keep things going smoothly. so you should keep people on pay-roll because they "might actually be doing something if you look hard enough" ...? don't think so > Pe…

> so you should keep people on pay-roll because they "might actually be doing something if you look hard enough" ...? don't think so

The point was that you might be making incorrect assumptions that they aren’t doing work, and you might be making incorrect assumptions that replacing them will cost less. Looking busy and knowing what to do are two different things.

Post reply on HN