needed • Naming: use fetch… instead of find… • Use pattern XYZ because I like it • No variable is used outside this method, so it could be static • Interface is better for exchange it later • We use fetch in other classes, for consistency use it here too • Explain why the pattern is better here
as done • Add label “xyz” so I can see if something changed • Discuss the usage of labels with the team • Don't use the review tool as your personal Todo list, management tool • Asked if you can block/negative influence other team members
I'm your team lead/boss/lead developer/head of xyz/senior developer • You're just a junior, listen to me • I'm not listen to what you say, because you're a junior/normal developer • Listen to the author • Asked why he thinks it's a good way • Say what can happen or what consequences it has • Talk to the author
listen to the author because I don't like the author • I'm not looking too close, because I trust/know the author • I ignore that you're not following the style guide, because I don't want to discuss with you • Treat everyone the same way • Just look at the code • Rules must be followed (or discussed again) -> team rules
also change XYZ in our application • I think the ticket should also include xyz • Suggest a following ticket for the other parts, maybe as a blocker • Stick to the original ticket • Suggest to stop the ticket and put in to “Not ready” again ( and learn from it)
Next time test it before the MR/PR. • I think it is right. It’s very complex. • Can you tell me how you tested it, so I can reproduce it? • Can you explain what id does? It’s complex and I don’t understand it (right).