1) What is the best approach to participating in daily standups? Should I provide an in-depth overview of my work, or focus on concise updates, blockers and areas where the team can help?
2) How can I effectively listen to and incorporate feedback from my manager and team? What strategies can I use to implement feedback constructively and improve my performance?
3) What are the best practices for communicating with remote team members?
4) How should I handle feedback from code reviews? What should I do if I don’t agree with the feedback?
5) How can I ensure my code meets the team's standards?
Great questions hyunbin! These questions are very good ideas for future articles to write:
1. From what I've seen, the purpose of a standup in industry is generally for each member of the team to provide their updates so that everyone is made aware of what the status of the current workstreams/projects are. Standups should/tend to be 15-20 minutes. I'd recommend providing a high level summary of what has been completed, what are the todos and are you stuck/blocked. If you are not sure about "what is a true blocker or not", I'd err on the side of communicating it so that your team can help if needed
2. Listening to feedback from your manager and team is so so vital. I strongly recommend treating any feedback like a gift. In terms of "how to effectively listen to feedback", I'd start with confirming that you heard the suggestion correctly. Saying something like "Just to make sure I understand correctly, you are suggesting that I should improve on X?" helps the feedback giver feel heard. In terms of the "incorporating feedback", this part can be very open ended. I'd recommend asking about a specific instance that motivated the feedback and any action items that you can adopt into your day to day workflow. Improvement on feedback doesn't necessarily come overnight. It will take time and after you have spent some time trying to internalize the feedback and action on it, it is fair to check in to see if you're moving in a good direction during 1:1s
3. The communication tips mentioned in this article (and the example provided) should highlight how one can effectively communicate with remote team members in an online workplace chat setting. I would also be happy to write a separate article on "Effective Communication" if there's popular demand for it
4. I'd recommend handling feedback of code reviews almost like handling feedback from your manager or team. Generally, code review feedback should be geared around the code and not necessarily a reflection about you as the developer. If there is feedback that you don't understand in the code review or you might disagree with, I'd recommend clarifying why the reviewer gave a certain suggestion. If there may be some pushback, you can disagree in a constructive way. We want to try to draw a bigger circle around you and the code reviewer. Both you and the reviewer are interested in high engineering quality, but maybe disagree at times on the details.
5. Most companies should have some sort of engineering standards documentation along with info on what extensions and tools should be setup for certain use cases. If you're ever in doubt about "best practice", you can always ask your team or it can be a discussion point during code review.
Hopefully this helps clarify. Feel free to followup if there is anything I can elaborate further on :)
Thanks for sharing! I suggest in your "Learn about the work" section to formulate your recommendations into questions - would be more actionable!
What are your thoughts on scheduling a meeting with your manager's manager? I'm not sure if that's applicable to all companies though, you'd definitely have to read the room on that.
Hey! Great question. I can totally formulate the "Learn about the work" section to have some actionable questions one should be able to answer.
In terms of "scheduling a meeting with your manager's manager?", I'd recommend giving it a try. Worst case scenario, maybe you get 1-2 meetings with your manager's manager (AKA as "skip manager")
Thanks for answering my questions! A few more:
1) What is the best approach to participating in daily standups? Should I provide an in-depth overview of my work, or focus on concise updates, blockers and areas where the team can help?
2) How can I effectively listen to and incorporate feedback from my manager and team? What strategies can I use to implement feedback constructively and improve my performance?
3) What are the best practices for communicating with remote team members?
4) How should I handle feedback from code reviews? What should I do if I don’t agree with the feedback?
5) How can I ensure my code meets the team's standards?
Great questions hyunbin! These questions are very good ideas for future articles to write:
1. From what I've seen, the purpose of a standup in industry is generally for each member of the team to provide their updates so that everyone is made aware of what the status of the current workstreams/projects are. Standups should/tend to be 15-20 minutes. I'd recommend providing a high level summary of what has been completed, what are the todos and are you stuck/blocked. If you are not sure about "what is a true blocker or not", I'd err on the side of communicating it so that your team can help if needed
2. Listening to feedback from your manager and team is so so vital. I strongly recommend treating any feedback like a gift. In terms of "how to effectively listen to feedback", I'd start with confirming that you heard the suggestion correctly. Saying something like "Just to make sure I understand correctly, you are suggesting that I should improve on X?" helps the feedback giver feel heard. In terms of the "incorporating feedback", this part can be very open ended. I'd recommend asking about a specific instance that motivated the feedback and any action items that you can adopt into your day to day workflow. Improvement on feedback doesn't necessarily come overnight. It will take time and after you have spent some time trying to internalize the feedback and action on it, it is fair to check in to see if you're moving in a good direction during 1:1s
3. The communication tips mentioned in this article (and the example provided) should highlight how one can effectively communicate with remote team members in an online workplace chat setting. I would also be happy to write a separate article on "Effective Communication" if there's popular demand for it
4. I'd recommend handling feedback of code reviews almost like handling feedback from your manager or team. Generally, code review feedback should be geared around the code and not necessarily a reflection about you as the developer. If there is feedback that you don't understand in the code review or you might disagree with, I'd recommend clarifying why the reviewer gave a certain suggestion. If there may be some pushback, you can disagree in a constructive way. We want to try to draw a bigger circle around you and the code reviewer. Both you and the reviewer are interested in high engineering quality, but maybe disagree at times on the details.
5. Most companies should have some sort of engineering standards documentation along with info on what extensions and tools should be setup for certain use cases. If you're ever in doubt about "best practice", you can always ask your team or it can be a discussion point during code review.
Hopefully this helps clarify. Feel free to followup if there is anything I can elaborate further on :)
Thanks for sharing! I suggest in your "Learn about the work" section to formulate your recommendations into questions - would be more actionable!
What are your thoughts on scheduling a meeting with your manager's manager? I'm not sure if that's applicable to all companies though, you'd definitely have to read the room on that.
Hey! Great question. I can totally formulate the "Learn about the work" section to have some actionable questions one should be able to answer.
In terms of "scheduling a meeting with your manager's manager?", I'd recommend giving it a try. Worst case scenario, maybe you get 1-2 meetings with your manager's manager (AKA as "skip manager")