[softfalcon]

I want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world.

Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else.

This might be isolated to the areas I work in, but I do find that the "10x engineer" myth seems to live on and prosper in far too many teams I've worked on. Despite how discouraging it is for the rest of us who want to play a "team sport".

[opportune]

How much of that is because those people aren’t being team players vs them learning things differently?

In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does.

As such I am not sure those people who know everything are secretly zealously guarding their information. Any brief explanation of something technical is simply too low-res compared to reading its implementation. So even if that person is super nice and tries to help as much as they can, I doubt anybody would learn as much as them just from secondhand information, as opposed to reading/writing/modifying the source themselves.

[RNCTX]

> In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does.

Depends on the shop.

The trend is toward people trying to standardize and automate as much of the development process as possible (so that they can get rid of domestic employees who cost to much and fetch it all over to people in exploitable-countries with less valuable currencies).

People who ask questions, push less ambitious changes, push buggy stuff that barely squeaks past the unit tests and then go back and improve it later if someone complains.. all of that leaves activity metrics that check boxes on the reports of people who don't care whether devs read and understand the existing code or not.

[riskneutral]

I share my screen and do an initial source code walkthrough of the overall structure of the project / component, and make sure they can build and run the code, before asking a junior team member to read the code themselves and figure the rest out on their own. It's worked really well, in my experience.

[Zababa]

> This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does.

As a junior, this is a problem for me too. I don't know when it's the right moment to ask something. "When I've been stuck for an hour to half a day" seems to be a good heuristic, but it's not perfect. I don't really know what's the best option for me. If I ask later, I learn more by myself, and improve my skills in figuring out a codebase. I also let senior engineers be more productive. If I ask earlier, I'm more productive. But I take more of the senior engineer's time.

Another heuristic I tend to use is "for code stuff, try asking later, for business stuff, try asking earlier", since business stuff is often harder to figure out. We have code that describes the behavior of our product, that I can read and try to understand, but we don't have code that describes the behavior of the business.

Same dilemma when adding comments. We code in a relatively "plain" style, so "how" comments are mostly useless. "why" comments are more useful, but people tend to not really update them.

I think a way of solving partially that would be to be clear about the meta stuff. For example, I could ask if I'm asking too much or not enough questions, if my productivity seems okay. The senior engineers could also communicate about that. Even sharing how they do themselves stuff would be useful. For example "I tend to look at the code for X minutes before asking someone.". As a junior, I could multiply this time by 2, 3, 4 and do the same. Or ask the seniors about how they did things when they were new to the codebase.

To give a bit of context, we have more than 10 MLOC at work on a 30+ years old codebase, ~200 engineers and half of them are there since 3 years or less.

[opportune]

Yeah, knowing when to ask questions is itself a skill. I didn’t mean to insinuate in my comment anything negative towards junior engineers or imply I hate when they ask questions. But I’d say knowing how to read code and understand it on your own vs recognizing when something is almost unknowable without asking someone is a hallmark of a more mature engineer. But I stand by my insinuation that people aren’t deliberately hoarding knowledge, they just learned what they know effectively (via primary sources and doing) rather than through hearsay or lectures. Or they “know how to know”, they seemingly know everything because they know how to find answers to any question.

What you say about business logic is definitely true. In general the more something is an “emergent” property or itself only a high level concept (eg “Why do we use Mesos?” “How do we implement load shedding?”) the better it is to ask. The more implementation specific (“Why won’t this compile? What does this error mean?”) the worse it is. It’s not only about the time to find something out but also how it can be found out - whether it’s a web search or codebase search away, or not. The other problem is the senior people you ask may not always know the answer of the top of their head, and in answering your question will have to answer it themselves - typically you want to avoid that too.

For one I would always be more than happy to truthfully answer a mentee’s question regarding if they are asking too much.

[Zababa]

> I didn’t mean to insinuate in my comment anything negative towards junior engineers or imply I hate when they ask questions.

That's not how I took it, sorry if this wasn't very clear but my point is that it's difficult on both sides, and it's interesting to share our struggles to see if we can find better ways to transmit knowledge.

> . In general the more something is an “emergent” property or itself only a high level concept (eg “Why do we use Mesos?” “How do we implement load shedding?”) the better it is to ask. The more implementation specific (“Why won’t this compile? What does this error mean?”) the worse it is. It’s not only about the time to find something out but also how it can be found out - whether it’s a web search or codebase search away, or not.

That's a great heuristic.

> The other problem is the senior people you ask may not always know the answer of the top of their head, and in answering your question will have to answer it themselves - typically you want to avoid that too.

I think that may be a good thing in some cases, as long as you don't demand/need the answer now and the question is good. If there's something that even senior people are not clear on, that's an opportunity to clarify things for everyone. I think that's what people mean when they talk about the value of new hires being able to see surprising stuff that feels normal to the people inside.

> For one I would always be more than happy to truthfully answer a mentee’s question regarding if they are asking too much.

That's great!

[908B64B197]

The issue is, it's faster to build a feature yourself than to coach a new hire to build it.

So if an org doesn't value mentoring and growing engineering talent, you'll end up with a few engineers doing most of the work and an org that magically can't scale.

Then you'll see the hiring side buying in on the cargo cult and trying to hire seniors with resumes matching their existing devs, then whining they can't hire them for cheap. At this point the business velocity has reached it's top speed.

[daemoncoder]

I have the opposite problem: colleagues who don't want to learn how to do anything new.

[halfmatthalfcat]

I work alongside a principal engineer who refuses to learn anything beyond what they learned 5+ years ago. It seems they got to the Senior level and just gave up learning. Makes no sense to me and is a detriment to all the more junior engineers in our team.

[pydry]

>Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else.

This is a classic defense mechanism for engineers trying to shore up their position.

There's a tug o' war going on between many companies and their employees wherein the companies are trying to make the employees expendable and the employees are trying to make themselves indispensable.

I found it mostly went away when I worked in companies where most people treated their current job as a stepping stone to the next rather than as their final destination but in companies in 2nd/3rd tier cities where everybody is married with kids and looking for stability....yea

The worst offender was a guy who was massively in debt, paid a shedload of child support, was not a great programmer and didn't interview well. He was sometimes openly hostile to my attempts to get information out of his head.

[heurisko]

> I found it mostly went away when I worked in companies where most people treated their current job as a stepping stone to the next rather than as their final destination but in companies in 2nd/3rd tier cities where everybody is married with kids and looking for stability....yea

My experience of this, is that working with colleagues with families meant things were more stable and predictable.

In comparison, the people treating the job as a stepping stone developed things for their CV, rather than for the good of the organisation.

I can see how your experience can also be true however.

[sershe]

I dunno about 10x engineers, but there definitely tends to be a person who knows everything on many teams. I noticed over time that if I need to ask a random question about project A, I always ping the same 1-2 people from team A for most As... then I feel bad that I'm always bothering them, start asking someone else, get vague/incorrect/lazy answers, and go back to the same person anyway ;)

I don't think it is always a senior person though... it's often a junior engineer who's been there a while.

[8note]

if your team relies a lot on senior engineers knowing things, there's a problem with your technical architecture. The knowledge should be look up-able, and tied in a clear way to the functionality.

I'm one of the folks with lots of knowledge atm, and there's a corollary that the moment you teach somebody enough that they know things, they leave the team. Putting that knowledge into databases, code, and config files is much more durable, and can have new things built off of it

[rowanG077]

Why do you feel a "10x engineer" is problematic in a team? You can have different types of players in team.