3 ms·

I would suggest a combination of pair-programming, coding dojos and code reviews with NO force to participate. 1. pair programming Pair programming, if done c

I would suggest a combination of pair-programming, coding dojos and code reviews with NO force to participate. 1. pair programming Pair programming, if done correctly, encourages you to communicate with your partner. If he is shy, he won't be to excited about it, so I would start giving him the possibility to attend a pair-programming session of two other developers working at a pretty trivial task. 2. coding dojos Participating a coding dojo and solving a problem in groups of 2 or 3 devs can support you not being shy about presenting your solution. A fizz-buzz unit testing dojo maybe would be too trivial, but I think adventofcode[1] may provide some interesting problems that have nothing to do with your daily tasks. 3. Code reviews Weekly 45 minute code reviews build up a regular practise and knowlege transfer. My recommendation would be that you start by having a conversation about a piece of code, that everybody likes to get into a positive mood. Presenting something that you are proud of can be a problem but discussing a problem about an existing solition is often a common ground. [1]: https://adventofcode.com/ https://adventofcode.com/

15457345234 3y ago
If the guy is just - for want of a better word - genetically shy and a sole-contributor type who likes to take tasks and bunker down and churn out code, implementing any of these suggestions will probably make them snap quit. I think the better question to ask here is, can you get the input you're looking for out of the guy through a method that best suits their style. These suggestions are very 'force the round peg into the square hole' - like; the guy's shy? ok, we'll fix that by ramming him into situations where shyness isn't permissible until he gets over himself. It may be better to figure out how they can best deliver their contributions; some people prefer to digest input and write emails than engage in a 'face to face' because they see that as inherently adversarial and tend to back down. At the end of the day, not everyone is going to be able to stand up and advocate loudly for themselves in a group scenario; that does not make them a bad contributor. You need to evaluate their ability and ensure that your processes do not mean that an insistence on 'face to face, talk it out, say what you mean' style of communication in the business results in their contributions getting steamrollered.
- froggy 3y ago
  Amen. When I read the OP's post, I thought it could have been my manager. I am reserved, not outgoing, but I'm a team player. I prefer to take tasks, especially larger ones and bunker down exactly as you said. I'm pretty useless in sprint refinements with asking questions in a group setting, but if I'm given a set of requirements or mockups, I'll knock it out of the park every time. Been doing it this way for almost decades now. I didn't snap quit when a previous employer started trying to get me more sociable but I was gone within a few months. OP would be well-served to take your suggestions if they want the developer to stay.
- sandreas 3y ago
  I really learned something from this post. Obviously till today I did not understand REALLY shy people, nor ever had a collegue THIS shy. If anyhow I ever get into such a situation, I feel better prepared. Thank you.
  - 15457345234 3y ago
    We aim to please

15457345234 3y ago

If the guy is just - for want of a better word - genetically shy and a sole-contributor type who likes to take tasks and bunker down and churn out code, implementing any of these suggestions will probably make them snap quit. I think the better question to ask here is, can you get the input you're looking for out of the guy through a method that best suits their style. These suggestions are very 'force the round peg into the square hole' - like; the guy's shy? ok, we'll fix that by ramming him into situations where shyness isn't permissible until he gets over himself. It may be better to figure out how they can best deliver their contributions; some people prefer to digest input and write emails than engage in a 'face to face' because they see that as inherently adversarial and tend to back down. At the end of the day, not everyone is going to be able to stand up and advocate loudly for themselves in a group scenario; that does not make them a bad contributor. You need to evaluate their ability and ensure that your processes do not mean that an insistence on 'face to face, talk it out, say what you mean' style of communication in the business results in their contributions getting steamrollered.

froggy 3y ago
Amen. When I read the OP's post, I thought it could have been my manager. I am reserved, not outgoing, but I'm a team player. I prefer to take tasks, especially larger ones and bunker down exactly as you said. I'm pretty useless in sprint refinements with asking questions in a group setting, but if I'm given a set of requirements or mockups, I'll knock it out of the park every time. Been doing it this way for almost decades now. I didn't snap quit when a previous employer started trying to get me more sociable but I was gone within a few months. OP would be well-served to take your suggestions if they want the developer to stay.
sandreas 3y ago
I really learned something from this post. Obviously till today I did not understand REALLY shy people, nor ever had a collegue THIS shy. If anyhow I ever get into such a situation, I feel better prepared. Thank you.
- 15457345234 3y ago
  We aim to please