3 ms·

I read it more as "everyone (in the team) should be responsible for the architecture (of their products)". So, it's the duty of every engineer (even junior ones

by danwee 4y ago

I read it more as "everyone (in the team) should be responsible for the architecture (of their products)". So, it's the duty of every engineer (even junior ones) to get to know more about the architecture of their products or to come up with decent architectures for future ones. Of course, some engineers know more than others (or have better taste). That's fine. It's pretty common nowadays that only the "tech lead" or the most senior engineers discuss architectural topics that affect the whole team, but the most junior engineers are left behind.

oppositelock 4y ago
I'm the tech lead of a sizable team, and what you describe, leaving junior engineers behind, would be a sign of failure on me. Large software systems are complex, and there is too much detail for any one person to dive deep into everything, so in my opinion, you discuss overall architecture with the team, but critically, you explain _why_ you are proposing a certain approach, because more junior people don't have this context. Then, you ask the other folks to help you go deep into investigations on whether your architecture is compatible with the details. If as a TL, you are not teaching and nurturing your young 'uns, you're doing a bad job.
- ric129 4y ago
  What if your young 'uns just do not... participate? I am in a position where I am doing TL-level decisions, and try quite hard to demo, discuss, share the details and rationale. I write design proposals, documentation, do demo sessions, etc But the information is just not flowing, and I notice how little the juniors participate in anything. And I don't exactly know what to put my finger on. It's probably some soft-skill I'm lacking, and that I do not know how to improve But a part of me still feels that that perhaps the young 'uns are just... too fresh. Or that the approach is just too optimistic
  - oppositelock 4y ago
    This is where people management comes into play. It's really difficult to identify why someone isn't participating, until you get to know their work and personality. I have regular meetings with all the engineers to discuss their work, progress, what is holding them back, expectations for career, growth, stuff like that. It's impossible to completely separate tech leadership from people leadership. In my experience, usually, lack of participation comes from a lack of self confidence in one's understanding of software development, and usually, finding something small and delegating ownership to a junior engineer, with some oversight, gets them to participate more. You have to let go of the notion of having something done perfectly and allow them to make their own mistakes, but don't let them make huge ones. This is the most common case. There are also people who don't care (can't do much here), or aren't very good technically.
    - waynesonfire 4y ago
      > lack of participation comes from a lack of self confidence Yep that's it... let's not have management or leadership take any responsibility. It's the subordinates fault of course.
AnimalMuppet 4y ago
One place I worked, there was an architecture. The intent was that every programmer on the project could reproduce the same diagram of the architecture on a cocktail napkin. The reason is so that all programmers can keep the architecture in their head, to help guide their work. If they have to go look it up, they probably won't. To make this work, the architecture needs to be somewhat simple. Architecture astronautics fail the "everyone can keep it in their head" test. I think they stole that idea (everybody has the architecture in their head) from Extreme Programming.

by danwee 4y ago

oppositelock 4y ago

I'm the tech lead of a sizable team, and what you describe, leaving junior engineers behind, would be a sign of failure on me. Large software systems are complex, and there is too much detail for any one person to dive deep into everything, so in my opinion, you discuss overall architecture with the team, but critically, you explain _why_ you are proposing a certain approach, because more junior people don't have this context. Then, you ask the other folks to help you go deep into investigations on whether your architecture is compatible with the details. If as a TL, you are not teaching and nurturing your young 'uns, you're doing a bad job.

ric129 4y ago
What if your young 'uns just do not... participate? I am in a position where I am doing TL-level decisions, and try quite hard to demo, discuss, share the details and rationale. I write design proposals, documentation, do demo sessions, etc But the information is just not flowing, and I notice how little the juniors participate in anything. And I don't exactly know what to put my finger on. It's probably some soft-skill I'm lacking, and that I do not know how to improve But a part of me still feels that that perhaps the young 'uns are just... too fresh. Or that the approach is just too optimistic
- oppositelock 4y ago
  This is where people management comes into play. It's really difficult to identify why someone isn't participating, until you get to know their work and personality. I have regular meetings with all the engineers to discuss their work, progress, what is holding them back, expectations for career, growth, stuff like that. It's impossible to completely separate tech leadership from people leadership. In my experience, usually, lack of participation comes from a lack of self confidence in one's understanding of software development, and usually, finding something small and delegating ownership to a junior engineer, with some oversight, gets them to participate more. You have to let go of the notion of having something done perfectly and allow them to make their own mistakes, but don't let them make huge ones. This is the most common case. There are also people who don't care (can't do much here), or aren't very good technically.
  - waynesonfire 4y ago
    > lack of participation comes from a lack of self confidence Yep that's it... let's not have management or leadership take any responsibility. It's the subordinates fault of course.

AnimalMuppet 4y ago

One place I worked, there was an architecture. The intent was that every programmer on the project could reproduce the same diagram of the architecture on a cocktail napkin. The reason is so that all programmers can keep the architecture in their head, to help guide their work. If they have to go look it up, they probably won't. To make this work, the architecture needs to be somewhat simple. Architecture astronautics fail the "everyone can keep it in their head" test. I think they stole that idea (everybody has the architecture in their head) from Extreme Programming.