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

111–120 of 146 posts

Re: How to Lead in a Room Full of Experts

#111

Post by fsckboy »

bruce511 wrote: post #85
atoav wrote: post #76

Earlier quoted context omitted.

Chances based on my experience? 50:50 Old engineers will say things that are hard learned lessons like "don't reinvent the wheel, when your thing is running on a system that comes with wheels". So, good solid advice that rookies will ignore, because of course they do. But sometimes old engineers will say things that are more of the quality of: "30 years ago went deep into this topic, discovered the truth and haven't…

I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today. For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently. Like using bits in a byte, or a byte as an ID field. Or quibbling over the length…

>many older folk...like using bits in a byte, or a byte as an ID field. Or quibbling over the length of a Name field. All those habits proved to be bad in the long run.

I'll bet you the people inventing these modern new architectures are among the more experienced engineers at the companies

who I would criticize by saying, we used to think it was a good idea to code around the limitations of old architectures and now we're accused of coding for PDP-11s and processors aren't PDP-11s any more. so what we should do now I'm told is code very specifically around the idiosyncracies of the new PDP-11,000's and that is what marks progress. Caches were invented to invisibly and silently make things faster, and that was a brilliant idea. Now new cache designers analyze what we used to do to insist we change how we code so they can cache what they want to cache not what we want to do, and all younger programmers talk about these days is coding for the cache (which itself is a cache of a cache of a cache). this is not progress, it's coding for the timing of the modern storage drum.

Re: How to Lead in a Room Full of Experts

#112

Post by rcxdude »

antonvs wrote: post #97
bruce511 wrote: post #85

Earlier quoted context omitted.

I'll second this. Unfortunately experience is a two-edged sword. I deal with a lot of old programmers and I continually hit the "fact" that was true in 1999 but is false today. For example, I started in DOS (as did many older folk). Memory was severely constrained. So we developed habits to use memory (and disk space) very efficiently. Like using bits in a byte, or a byte as an ID field. Or quibbling over the length…

> today memory (and disk space) are abundant. It still has a cost though, which needs to be taken into account in many situations. At our company the cost of compute, RAM, and storage are some of the biggest ongoing concerns, which can make the difference between profitability and bankruptcy, and we’ve done a lot of work on it.

Especially in the cloud, where RAM is extremely expensive, and you're encouraged to go for very ram-inefficient horizontal scaling architectures.

Re: How to Lead in a Room Full of Experts

#113

Post by benchly »

I've been part of three software-adjacent product development teams where the Lead did exactly this and it did not go well all three times.

Having been team lead a few times myself now, I have learned that I am not there to be a field marshal. I'm there to act as a hub or conduit for all the other parts of the team. When they clash, I help resolve the conflict. When they question, I help assuage concerns. When they have ideas, I help evaluate the value of implementation. When they need resources, I approach the right people and do what I can. When they fuck up, I take the heat and rally them to help fix the problem.

It took me over a decade to learn this. I'm not the best. My name is unrecognized, for the most part, outside of some very specific circles. But I find that being part of the team rather than some imaginary demagogue to them yields consistently good results with significantly lower risk of talent loss and helps avoid over-promising/under-delivering.

The article does a nice job of pointing a few things out that I find essential in good leadership, but one thing in particular is saying "I don't know, but let's figure it out." Not only does it give your experts permission to be uncertain and helps avoid the trappings of getting defensive, as the author mentions, but it also reminds them they are not alone in this fight. That's powerful.

I'm sure many of you reading this have felt unsupported by your leaders in the past, a cog in a machine that will stress you to the point of breaking and simply replace you with another when that inevitably happens. Maybe my experience as a tech/troubleshooter colors my view here, but people, just like machines, need to be cared for if you want them to keep operating at a level that allows them to make a meaningful contribution to the team.

Re: How to Lead in a Room Full of Experts

#114

Post by becarlos »

atoav wrote: post #102
cradsoit wrote: post #91

Earlier quoted context omitted.

You can still obtain a ton of performance by minimizing the size of right things, processor caches are relatively small still. Stuff like the order of columns in a postgres database can still at worst multiply your table size

Yes, but we went from a time where these optimizations were absolutely unavoidable (so unavoidable that programmers would sacrifice any other thing for it) to one where the optimizations may be a nice to have, but for most organizations the maintainability of the code is much more crucial. As mentioned before there are exceptions, like embedded programming, anything that needs to be finished within predictable time (…

With 20 years of experience in website development, I have led various site speed optimization teams. From my background, I pay particular attention to assets, JS profiling, and related aspects whenever I work on a web app. These practices are so ingrained that I perform them automatically and transparently, as they have been part of my process ever since.

The same thing might happen to these engineers when working on existing or new projects and writing C/C++ code; these optimizations will be part of their process.

Re: How to Lead in a Room Full of Experts

#115

Post by jmpeax »

> Leadership in technical environments isn't about being the smartest person in the room. It's about being the most effective translator.

Only if you don't make the final decision, but if you do, you better be the smartest person in the room by far. Otherwise, you're not a leader but a post turtle.

Re: How to Lead in a Room Full of Experts

#116

Post by joncrane »

BrandoElFollito wrote: post #110
fsckboy wrote: post #109

Earlier quoted context omitted.

> First I am not sure what you mean by "know-it-all"...if you drop "older" good lord, in those phrases he was quoting the wording in the comment he was replying to. I don't know if you are young or old, but I'd like to teach you about threading (and we won't stop till you get it or your eyebrows are gone)

I have no idea what you are talking about. Could you please rephrase this in simple words adapted to my age?

The post that this thread is replying to uses the phrase "know it all" and it's pretty obvious what OP meant.

The person kvetching at you about not understanding threading is making a joke because there's also a process called "eyebrow threading."

HN is supposed to be high quality discourse and you have to be on your toes if you want to participate!

Missing context, and missing references, and doubling down when you're called out is NOT the optimal strategy.

Re: How to Lead in a Room Full of Experts

#117

Post by BrandoElFollito »

joncrane wrote: post #116
BrandoElFollito wrote: post #110

Earlier quoted context omitted.

I have no idea what you are talking about. Could you please rephrase this in simple words adapted to my age?

The post that this thread is replying to uses the phrase "know it all" and it's pretty obvious what OP meant. The person kvetching at you about not understanding threading is making a joke because there's also a process called "eyebrow threading." HN is supposed to be high quality discourse and you have to be on your toes if you want to participate! Missing context, and missing references, and doubling down when you'…

> HN is supposed to be high quality discourse and you have to be on your toes if you want to participate!

I am so sorry not to be at the correct level and, as a non English speaker, not to know all the references.

I feel so ashamed, fortunately you enlightened me about the high quality discourse I was missing.

Thank you very much for your kindness.

Re: How to Lead in a Room Full of Experts

#118

Post by BenoitEssiambre »

tombert wrote: post #77
mrngm wrote: post #42

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=43925892 "Microservices are a tax your startup probably can't afford" (310 points, 263 comments). First build the thing that works, and only if it's really necessary, split it up in separate (networked) parts. You won't have to deal with unreliable network communication, or coordinate on a breaking API change with several teams when a simple search/replace on several function defi…

I agree, though well designed software, even big monoliths, can be written in a way that isn't too hard to distribute later. For example, if you utilize asynchronous queues everywhere, instead of something like a shared-memory mutex, it's relatively straightforward to turn that into some kind of networked queue system if you need to. Pretty much every language has a decent enough queue implementation available.

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.

Re: How to Lead in a Room Full of Experts

#119

Post by skeeter2020 »

ahmedfromtunis wrote: post #5

"I'm the lead, and we are going to do it this way": avoid it for as long as you can, but do NOT hesitate to use it when it's the appropriate answer. Take the time to listen to everyone and to form an educated decision. Explain your conclusion once, twice and even thrice. But sometimes teams can get caught in an endless futile discussion over details that don't matter for the stated goals. In that case, it's *your dut…

In my most recent role I only pulled rank twice in more than 3 years. Both times, reluctantly and deliberately. I agree you want to build a LOT of trust and legitimacy before you do this and you can still build concensus once you've dictated a direction or path. Lead, don't micro-manage.

Re: How to Lead in a Room Full of Experts

#120

Post by skeeter2020 »

YZF wrote: post #73
Aurornis wrote: post #10

Earlier quoted context omitted.

This is a lesson I learned the hard way. When I was a first time manager I had the naive idea that I was going to build consensus for everything and get everyone to come to an agreement naturally. It worked at first with a good team. Then later I inherited a fragment of another team with some older know-it-all engineers who thought everything modern was garbage and we should be doing everything like they did 25 years…

What are the odds that the older know-it-all engineer actually knows better than you? I would say they're pretty good. That's not to say that consensus always works. But it does mean the group needs to understand the objections and make decisions the team can live with. The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the…

>> The most toxic of engineering situations is the manager making decisions without understanding consequences and without taking responsibility for the outcomes.

Disagree. This can be very bad, but the worst situation I had was a very experienced developer with poor social skills making decisions for the team without a complete understanding of the entire picture

Post reply on HN