3 ms·

1. At least daily with the whole team, and whenever you have something to discuss with someone individually. Be available on Slack (/Teams...). Announce relevan

1. At least daily with the whole team, and whenever you have something to discuss with someone individually. Be available on Slack (/Teams...). Announce relevant things on group chat (like a new API function becoming available, release dates...). 2. As often as the manager wants to. If you don't need anything from them, most are happy to be left alone as long as you deliver. 3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone. 4. I am not a huge fan of extensive documentation, because most people don't read it anyway and it gets out of date quickly. Just cover how to get started, and the overall structure so people can navigate. Keeping it short makes it more likely that someone actually reads it. But how much documentation you need depends on the organisation and project. It doesn't really matter whether you write it yourself or someone in the team. If you're lucky, someone in your team enjoys doing it. Just use some wiki-like system to make it easy to contribute. Or keep it in the repository as Markdown, if it's only for devs. 5. Depends on the project and team. But I have often tried to minimize the number of tasks I do myself, because as you suggested, it's hard to work on something when you're constantly being interrupted. In some teams I haven't worked on any tasks myself. 6. Talk to people and review their code. It's super-important to review as soon as the code is available, to minimize downtime and reduce context switching for the team members. Prioritize team members' code over your tasks! (Some people also suggested pair programming. If it works for you, great, but I am terrible at it. Hard to explain, but coding and speaking are two very different things for my brain. I can't write good code while talking about it, and the whole thing is very stressful for me. I prefer to discuss code asynchronously or on Slack).

pavel_lishin 2y ago
> 3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone. Be fucking ruthless about this. If someone starts digging down into details that only affects them or one other person, postpone that discussion - otherwise, your standups will balloon into hour-long semi-pairing sessions while the rest of your team's attention wanders. And ensure that the rest of your team is empowered to call that out, too - "Can we do a sync about <Topic X> after standup?" > (Some people also suggested pair programming. If it works for you, great, but I am terrible at it. Hard to explain, but coding and speaking are two very different things for my brain. I can't write good code while talking about it, and the whole thing is very stressful for me. I prefer to discuss code asynchronously or on Slack). I find myself having trouble here, too, but one thing that helps is not feeling the pressure to be talking and/or typing and/or reading all at once, for a long time. Allow yourself and your pairing partner to just sit quietly and think during pairing. I also "cheat" - before pairing with someone to support them on a problem they're having, I look at the code myself, first, and start diagnosing things. This prevents the issue of sitting there and staring blankly at code, hemming and hawing while you're trying to explain your thought process at the same time you're having the thoughts.

pavel_lishin 2y ago

> 3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone. Be fucking ruthless about this. If someone starts digging down into details that only affects them or one other person, postpone that discussion - otherwise, your standups will balloon into hour-long semi-pairing sessions while the rest of your team's attention wanders. And ensure that the rest of your team is empowered to call that out, too - "Can we do a sync about <Topic X> after standup?" > (Some people also suggested pair programming. If it works for you, great, but I am terrible at it. Hard to explain, but coding and speaking are two very different things for my brain. I can't write good code while talking about it, and the whole thing is very stressful for me. I prefer to discuss code asynchronously or on Slack). I find myself having trouble here, too, but one thing that helps is not feeling the pressure to be talking and/or typing and/or reading all at once, for a long time. Allow yourself and your pairing partner to just sit quietly and think during pairing. I also "cheat" - before pairing with someone to support them on a problem they're having, I look at the code myself, first, and start diagnosing things. This prevents the issue of sitting there and staring blankly at code, hemming and hawing while you're trying to explain your thought process at the same time you're having the thoughts.