Comment by foolfoolz
2 years ago
this post is really strange because it actually describes a good environment
- code isn’t changing in code review except for really good reasons
- people who need help are reaching out
- projects that need help get additional help brought in
what else are you looking for? this example is about as pair programming as it gets at most places. they’re called silos when people don’t like them and layers of abstraction otherwise but they’re the same thing: no team will have 100% shared info on all parts and knowledge transfers on exits are a decent step to bridge this
if you want to teach the team more, teach them more. usually the best way to do this is in code review. it’s direct comments on code. write a good review you want more people to see? post it in the chat. set up additional time to share ideas with the team. all of these things you can do as an IC while producing code
sorry but this post comes off as “i’m smarter than everyone.” i’m guessing the reason management hasn’t gotten your message is the message isn’t clear. what exactly do you want to do? and what do you need their help for?
I don't think code reviews are the _best_ way to teach. Because for a start, you're usually working with a complete task. Someone can have a perfectly fine pull request that implements the feature or solves the bug, but it might not be the best way of going about it.
Now, as a reviewer your spidey sense tingles and you get the feeling there's a better way. But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this".
Pair programming would get you on the right track from the start. You are able to assist an inexperienced dev and guide them through the process step by step. Imbuing your knowledge, raising questions, suggesting fixes. This is exactly what the blog post describes. The developer was seen as unproductive because their time was spend pair programming rather than directly doing the work themselves.
I don't see how my post comes across as "I'm smarter than everyone". I know things that less experienced developers don't know, and that's a fact I know from talking to them and reviewing their code. But the culture just isn't there to be able to spend significant portions of my day effectively being their teacher (which I would love to do!). Instead it's often "the blind leading the blind" while the more senior members of the team are off delivering important projects and not having the capacity to imbue their knowledge onto the less experienced members of the team.
It's a culture thing and I wouldn't say it's a good environment for nurturing new staff. Spending 2 hours in a Teams call or at someone's desk is uncomfortable for both parties in a company that doesn't encourage this sort of collaboration. And so there's a sense to not "waste someone's time". The person you're helping sees themselves as a burden rather than seeing themselves as a student. And as a teacher, you're conscious of the other work you're supposed to deliver because it's not expected for you to be spending significant parts of your day pair programming.
> But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this"
this is your issue. you’re approving prs due to perceived time constraints that you wish you could say no to. are these time constraints real? even for significant prs of 1-2k lines responding to a comment of rewrite another way only takes 1-2 days. code review isn’t about finding the best solution. it’s the best solution given the current trade offs. things to ask yourself are
- are the time constraints real?
- does the team agree on the “right” way?
if there’s time constraints sure i get it. these are external commitments. public deadlines. it’s hard to ask for additional work like this. but in my experience these are rare. usually management is smart enough to avoid external deadlines
does the team agree this is the right way? are you pushing your own narrative? if it’s a team strategy, it’s very easy to tell people to rewrite an entire pr for. if it’s your opinion but you can defend it, make your case, and if it’s strong you can still get someone to write it. is this so bad it’s going to be rewritten soon?
> the more senior members of the team are off delivering important projects and not having the capacity to imbue their knowledge onto the less experienced members of the team
i thought you were saying you are this senior engineer?
i don’t get this. you want to spend more time helping people but think it’s uncomfortable to be on a call with someone for 2 hours getting through a problem. you want to pair program and feel this way about a shared coding session? i’ve spent literally 7 hours on zoom screen shares. if you’re actually helping people they appreciate it
you say the culture isn’t there to support this but then list examples of good places you could create this culture and choose not to
if you truly are this smarter, better engineer that should spend all your time helping your team, why aren’t you doing these things on your own?
I think you're viewing this in a very idealistic way and not a way many companies actually operate.
You can me ask "why don't you do X". And the answer is that the culture does not support it. I have work to do, work I've been given because as senior members of the team we are pushed into bigger and more important projects. The less experienced members of the team just have more time to do things.
For me to spend 7 hours a day sitting in a call with someone would mean 7 hours of not delivering work that my manager and project managers expect to be delivered. No person in the business is going to want to spend 7 hours on a call because the culture does not encourage it. This is why I said it is uncomfortable for both parties. Taking hours of someone's time isn't seen as a good thing, it's seen negatively. Of course the person you're helping appreciates it. But the culture makes them feel guilty for asking.
Should that be the case? No. Is that the case? Yes. Am I working toward that not being the case? Yes.
I don't know why you think I'm not trying to change the culture. I've literally listed all the issues and ways to fix it. It's not an overnight switch.