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

How to Lead in a Room Full of Experts

idiallo.com

Post reply on HN
Print view View original

141–146 of 146 posts

Re: How to Lead in a Room Full of Experts

#141

Post by BenoitEssiambre »

tombert wrote: post #136
BenoitEssiambre wrote: post #118

Earlier quoted context omitted.

Asynchronous queues make your data out of sync (hence the name) and inconsistent one of the main downsides of microservices. Their use should be minimized to cases where they are really necessary. A functional transactional layer like postgres is the solution to make your state of truth accessed in a synchronized, atomic, consistent way.

No, I disagree with that completely actually. Functions and handlers should not care where data comes from, just that they have data, and a queue is the abstraction of that very idea. Yes, you lose atomicity but atomicity is generally slow and more problematic has a high amount of coupling. I don’t agree that being out of sync is the main downside of microservices; the main downside is that anything hitting the netwo…

I'll agree that the network layer adds more problems to microservices, but even with a perfect network, they are problematic. Everything being out of sync, (if they are stateful microservices which queues imply), is one big issue. Things being interconnected in broad global scopes instead of more locally scoped is the other big issue.

The more you have globally interconnected and out of sync states, the less predictable your system is.

The solution is to be as hierarchical, as tightly scoped, as functional and as transactional as you can.

That's how you tackle complexity and create intelligent systems: https://benoitessiambre.com/entropy.html

Re: How to Lead in a Room Full of Experts

#142

Post by tombert »

BenoitEssiambre wrote: post #141
tombert wrote: post #136

Earlier quoted context omitted.

No, I disagree with that completely actually. Functions and handlers should not care where data comes from, just that they have data, and a queue is the abstraction of that very idea. Yes, you lose atomicity but atomicity is generally slow and more problematic has a high amount of coupling. I don’t agree that being out of sync is the main downside of microservices; the main downside is that anything hitting the netwo…

I'll agree that the network layer adds more problems to microservices, but even with a perfect network, they are problematic. Everything being out of sync, (if they are stateful microservices which queues imply), is one big issue. Things being interconnected in broad global scopes instead of more locally scoped is the other big issue. The more you have globally interconnected and out of sync states, the less predicta…

I think we are at a fundamental disagreement on this.

You can make asynchronous code predictable if you utilize something like TLA+, or treat the code as a protocol system.

Re: How to Lead in a Room Full of Experts

#143

Post by liquid_thyme »

AdieuToLogic wrote: post #138
liquid_thyme wrote: post #88

Earlier quoted context omitted.

I've worked with engineers like this, who have a massive god-complex. If you think your job is to second guess your manager's knowledge and experience, why are you working under them? You should be working as a manager somewhere else. You are not a peer, you're part of a team reporting into a person that company has entrusted to lead the team.

> I've worked with engineers like this, who have a massive god-complex. Championing collaboration in a team environment where members are employed for their skills is to acknowledge the value of those members. How you equate this to "a massive god-complex" is a mystery to me. > If you think your job is to second guess your manager's knowledge and experience, why are you working under them? Again, collaboration is not…

The only thing that matters is - Have you personally implemented your ideas in the real world or not? I don't care much for theoretical mumbo jumbo. You keep doing your thing and I'll keep doing it my way that I know works. It is irrelevant what you can "confirm" about me and my views - what a pompous thing to say!

Re: How to Lead in a Room Full of Experts

#144

Post by AdieuToLogic »

liquid_thyme wrote: post #143
AdieuToLogic wrote: post #138

Earlier quoted context omitted.

> I've worked with engineers like this, who have a massive god-complex. Championing collaboration in a team environment where members are employed for their skills is to acknowledge the value of those members. How you equate this to "a massive god-complex" is a mystery to me. > If you think your job is to second guess your manager's knowledge and experience, why are you working under them? Again, collaboration is not…

The only thing that matters is - Have you personally implemented your ideas in the real world or not? I don't care much for theoretical mumbo jumbo. You keep doing your thing and I'll keep doing it my way that I know works. It is irrelevant what you can "confirm" about me and my views - what a pompous thing to say!

> The only thing that matters is - Have you personally implemented your ideas in the real world or not?

Yes.

And I have made the mistake of "being a dictator" early in my career, only to learn that collaboration and valuing team members yields success much more often than me unequivocally imposing my viewpoint due to reporting structure.

> It is irrelevant what you can "confirm" about me and my views - what a pompous thing to say!

If you have management philosophies which differ from the limited communications in this thread, then obviously I am unaware of them until and unless you decide to share them here. Until such time, all I can do is draw conclusions from what you have posted thus far.

As to "what a pompous thing to say!"

This is the second time in this thread you have projected a judgemental position regarding my prose. The first time can easily be rationalized as perhaps a reaction "in the moment" or a poor choice of words. Now that you have done so again, I have to surmise the origin resides in yourself.

Re: How to Lead in a Room Full of Experts

#145

Post by antonvs »

9rx wrote: post #130
antonvs wrote: post #128

Earlier quoted context omitted.

> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something? This doesn’t seem realistic to me. Division of labor also implies division of decisions. Mature individuals and teams will acknowledge when there are decisions they’re not able to make, and will refer them to the relev…

> An obvious example of this is legal How is that an example? Legal is just an input. A mature individual is going to heed the advice from legal, most certainly, but legal isn't making the final decision. Legal doesn't know anything about all of the other constraints, like customer need and technical need. If they did, they wouldn't be working as legal council, they'd be doing the job we're talking about. So, we're r…

> Legal is just an input

An input that regularly mandates choices. The idea that an engineering team gets to make choices with legal consequences using legal as just an "input" is not consistent with any large company I've ever worked at.

> If you don't think they're capable of listening to the same things as you are, taking into account team guidance, and coming to a reasonable decision, why would you trust them to implement something?

Because different people have different skills and knowledge. As I said previously, division of labor also implies division of decisions.

People are not interchangeable or fungible components.

Re: How to Lead in a Room Full of Experts

#146

Post by 3abiton »

csbrooks wrote: post #41

In my experience, you don't really want to say "I'm the lead" (it can come across insecure), but you do need to be able to confidently say "Ok, here's what we're going to do" or "Here's what I'd like you to do" once you've gathered all the relevant information and come to a decision.

At the end of the day that's the end goal of technical leadership: trust in the team ability and educated decision making
Post reply on HN