Do you mean to say junior devs should be a part every single meeting held by senior engineers? This is utter nonsense, sorry.
Do you mean to say junior devs should be a part every single meeting held by senior engineers? This is utter nonsense, sorry.
Regardless of whether juniors attend “senior” meetings or not, seniors should be transparent with juniors by showing them exactly how they should be operating —especially around operational subjects. Using language which isn’t common to all team members (whether Russian, English or any other language) is not the way to build a healthy team of people, in my experience.
And I think they should be given the option to attend all other meetings too, maybe with the exclusion of those that are more business oriented like discussing the vision for the team with management, etc. It has to stay efficient.
Otherwise, how do you want your junior developers to not be junior at some point?
I wouldn't want to work for your company.
> And I think they should be given the option to attend all other meetings too,
Surely we had numerous meetings altogether, she wasn't excluded. But if every engineer would be given the right to attend every meeting, this would pretty much degrade to everyone just holding meetings all day long.
> I wouldn't want to work for your company. Thanks for sharing! There are quite a few companies that follow your vision, I wish you good luck in your career.
How? Better. Because they understand more about the reasons why a system is a particular way.
When? The other 30 hours of the work week? My team is meetings heavy yet we all have time to do actual work.
A big part of being a senior software engineer is growing others. I'm not sure you're a senior engineer yourself, despite your belief in it.
I have two policies for casual work-related discussions:
- discussions should have outcomes
- it shouldn't exclude anyone (not the same as: it should include anyone!)
...and a simple policy for non-work related discussions:
- feel free to chat about private topics however and to whomever you prefer
So:
- try to schedule meetings for important things and make anyone that could/wants to learn from it feel included
- if it's just casually pondering about architectural things and there is an outcome, you are obliged to provide a non-exlusive summary to the other team members (and should be able to give a reason on why this discussion was taking place exclusive to others like it did)
- and, if there isn't an outcome, the discussion wasn't worth its time and there shouldn't be a need to involve anybody else