5 ms·

I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You

I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good reason. But it's usually contained to someone like a junior calling me up and saying "can you help me?". The answer is always "yes of course!" and I share as much as I possibly can. But it ends there. I just want to sit down and show them things. Teach them in a way that makes things "click" the way I found they clicked with me. But I don't think management really values this approach. We get siloes of knowledge and then when someone leaves it's all hands on deck to transfer that knowledge. I'm often brought onto projects as a firefighter because I'm seen as productive. But I think the more important thing for the team would be to have me upskill everyone else below me. But for whatever reason, it's hard to get that point across to management. I can see myself in a few people and that they have potential, they just need encouragement.

segfaltnh 3y ago
Frankly it sounds like you need to make this happen. I don't know your company culture but at places I've worked Staff+ engineers aren't meant to wait around for permission to be catalysts and mentor other engineers.
- Philip-J-Fry 3y ago
  I'm usually the catalyst for change, but that's usually around tech and process. It's more effort for me to try and change my managers mind on what our development culture should be. The company I work for has a reputation for being a bit of a grinder and I've managed to help reduce that reputation in my team gradually at least. But at the moment I have work to do and deadlines to meet, so it's a hard sell to suggest stepping back from active development and focusing more on incubating our less experienced devs. Even though it's better in the long term, and my manager would even agree on that, important short term projects just take priority.
  - nevertoolate 3y ago
    Optimizing team efficiency is a team effort. It is a false dichotomy that you either work on “important project with deadline” or do mentoring. There are deeper structural problems that you need to solve first imo.
politelemon 3y ago
Yes very similar. It makes me very happy when I'm called over by a junior proactively. Not mainly because I'm able to help them, the real reason is that they sensed something about the problem that needed a second pair of eyes, and they didn't waste time. That's them gaining intuition and experience and I get really happy for them. I don't actually say it though because I don't know how to express it.
raincom 3y ago
In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.
- rawgabbit 3y ago
  Seeking help isn’t the problem. It is priorities. Usually the best developers are tasked with the more impactful tasks whose deadlines must be met at all costs. As a manager, I would view my task is to shield said developer from distractions so he can save my butt because my job is also on the line.
- jonhohle 3y ago
  If someone is intentionally giving bad advice, that sounds like they deserve some anytime feedback. (is that still a thing?) That is definitely not thinking like an owner.
- BirdieNZ 3y ago
  > One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Which senior manager is this, out of interest?
  - lolinder 3y ago
    Name-and-shame culture on the internet is toxic and ruins innocent people's lives. When someone conscientiously keeps a person anonymous while describing one or more of their flaws, there's no need to ask them to name the guilty. There's enough unnecessary permanent reputational damage going around on the internet already.
rjbwork 3y ago
Apparently I am pretty lucky. My managers are explicitly asking me to help rescue a project AND get the dev who did most of the work upskilled and following some of our patterns from some other successful projects. It is hard to know whether they are actually taking my advice and changes to heart and integrating them into their knowledge base and mindset, or just accepting that they're being asked to make changes by me and doing them. Mentorship is hard, regardless of management buy in :/
foolfoolz 3y 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?
- Philip-J-Fry 3y ago
  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.
liquidpele 3y ago
Have juniors plan out work first in design doc form and broken up into small deliverables. Helps to catch things early when they start down a rabbit hole.
sodapopcan 3y ago
Pairing gets a lot of hate and is very misunderstood. It can be terrible, though, if the org doesn't encourage and teach it. There are also lots of things about pairing that are misunderstood, especially that things take more time. I was on a team that paired all the time and it's sort of ruined me for anything else. We switched pairs daily and everyone would pair with everyone else (on the team). When a junior joined the team they would very quickly lose their junior status.
jimmaswell 3y ago
Pair programming sounds so stressful and unproductive to me. You can't read someone's mind. Any interjections while someone is in the middle of coding can't be more than distracting noise most of the time. And I would constantly feel self conscious that I'm taking too long to write something, googling or asking Copilot stupid questions, etc. Reviewing after the programmer believes it's ready to review makes much more sense to me. Though Copilot can be very helpful as an artificial pair programmer.
- teirce 3y ago
  The point of pair programming isn't really to be talking to someone while they are coding a known solution. It's to work through and discover a solution together to an unknown. In this sense, you're kind of both in the same headspace together, and can have a conversation without necessarily breaking focus. And I would venture that almost any question that comes up in pair programming would either come up later in code review, or could be hand-waved with "yeah, I plan to fix that with X" and move on. The important part of pair programming isn't really the programming per se, it's the discussion. It also requires some amount of conversational art. As for being self conscious about things, you would have poor coworkers who make you think that or some unfounded worry. A good pair programmer can have a discussion without making you feel like an idiot - much the same as a good code review.
- robryan 3y ago
  I agree with you for a case where you are taking a feature from start to end. The case where you are spending half an hour unblocking someone who is stuck or brainstorming a better solution for something tends to be beneficial though.
- willsmith72 3y ago
  I used to think the same until I was put in an environment where it was normal and where everyone was trained in pairing. Copilot is as much a pair programmer as stack overflow is... So not at all

segfaltnh 3y ago

Frankly it sounds like you need to make this happen. I don't know your company culture but at places I've worked Staff+ engineers aren't meant to wait around for permission to be catalysts and mentor other engineers.

Philip-J-Fry 3y ago
I'm usually the catalyst for change, but that's usually around tech and process. It's more effort for me to try and change my managers mind on what our development culture should be. The company I work for has a reputation for being a bit of a grinder and I've managed to help reduce that reputation in my team gradually at least. But at the moment I have work to do and deadlines to meet, so it's a hard sell to suggest stepping back from active development and focusing more on incubating our less experienced devs. Even though it's better in the long term, and my manager would even agree on that, important short term projects just take priority.
- nevertoolate 3y ago
  Optimizing team efficiency is a team effort. It is a false dichotomy that you either work on “important project with deadline” or do mentoring. There are deeper structural problems that you need to solve first imo.

politelemon 3y ago

Yes very similar. It makes me very happy when I'm called over by a junior proactively. Not mainly because I'm able to help them, the real reason is that they sensed something about the problem that needed a second pair of eyes, and they didn't waste time. That's them gaining intuition and experience and I get really happy for them. I don't actually say it though because I don't know how to express it.

raincom 3y ago

In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.

rawgabbit 3y ago
Seeking help isn’t the problem. It is priorities. Usually the best developers are tasked with the more impactful tasks whose deadlines must be met at all costs. As a manager, I would view my task is to shield said developer from distractions so he can save my butt because my job is also on the line.
jonhohle 3y ago
If someone is intentionally giving bad advice, that sounds like they deserve some anytime feedback. (is that still a thing?) That is definitely not thinking like an owner.
BirdieNZ 3y ago
> One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Which senior manager is this, out of interest?
- lolinder 3y ago
  Name-and-shame culture on the internet is toxic and ruins innocent people's lives. When someone conscientiously keeps a person anonymous while describing one or more of their flaws, there's no need to ask them to name the guilty. There's enough unnecessary permanent reputational damage going around on the internet already.

rjbwork 3y ago

Apparently I am pretty lucky. My managers are explicitly asking me to help rescue a project AND get the dev who did most of the work upskilled and following some of our patterns from some other successful projects. It is hard to know whether they are actually taking my advice and changes to heart and integrating them into their knowledge base and mindset, or just accepting that they're being asked to make changes by me and doing them. Mentorship is hard, regardless of management buy in :/

foolfoolz 3y 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?

Philip-J-Fry 3y ago
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.

liquidpele 3y ago

Have juniors plan out work first in design doc form and broken up into small deliverables. Helps to catch things early when they start down a rabbit hole.

sodapopcan 3y ago

Pairing gets a lot of hate and is very misunderstood. It can be terrible, though, if the org doesn't encourage and teach it. There are also lots of things about pairing that are misunderstood, especially that things take more time. I was on a team that paired all the time and it's sort of ruined me for anything else. We switched pairs daily and everyone would pair with everyone else (on the team). When a junior joined the team they would very quickly lose their junior status.

jimmaswell 3y ago

Pair programming sounds so stressful and unproductive to me. You can't read someone's mind. Any interjections while someone is in the middle of coding can't be more than distracting noise most of the time. And I would constantly feel self conscious that I'm taking too long to write something, googling or asking Copilot stupid questions, etc. Reviewing after the programmer believes it's ready to review makes much more sense to me. Though Copilot can be very helpful as an artificial pair programmer.

teirce 3y ago
The point of pair programming isn't really to be talking to someone while they are coding a known solution. It's to work through and discover a solution together to an unknown. In this sense, you're kind of both in the same headspace together, and can have a conversation without necessarily breaking focus. And I would venture that almost any question that comes up in pair programming would either come up later in code review, or could be hand-waved with "yeah, I plan to fix that with X" and move on. The important part of pair programming isn't really the programming per se, it's the discussion. It also requires some amount of conversational art. As for being self conscious about things, you would have poor coworkers who make you think that or some unfounded worry. A good pair programmer can have a discussion without making you feel like an idiot - much the same as a good code review.
robryan 3y ago
I agree with you for a case where you are taking a feature from start to end. The case where you are spending half an hour unblocking someone who is stuck or brainstorming a better solution for something tends to be beneficial though.
willsmith72 3y ago
I used to think the same until I was put in an environment where it was normal and where everyone was trained in pairing. Copilot is as much a pair programmer as stack overflow is... So not at all