| > The best way I've found to interrupt it is to ask myself "what if they're right" and/or "in what way might this person be right that I may not have considered"? There's also a great question to ask yourself even before those: is it worth it? A lot of times just ignoring improvements you can see/sense is the right call. Every time you bring up a suggestion (whether it is to a teammate or to yourself) your are affecting the environment in ways that can compound. For instance: - You may break the creation flow, interrupting the far more important "advancing to the greater goal" by perfecting a middle-step that matters much less and can be easily corrected afterwards if need be. - You are de-valuing your future suggestions/feelings, because the more stuff you bring up, the less weigh they get in the long run. - You risk lowering your teammate's confidence / degrading your relationship (just like you were doing in your story). If you are one of these people who just cannot "let something go", what you can do is write that thing down. Just make a note "revisit X thingy" and come back to it later when the rest is done/clear. This should allow you to actually move forward towards the "big picture" with a clearer mind (i.e.: without having that thread stuck wasting effort on what you just "ignored"). Finally, if the issue is important enough that it requires solving to advance, another great attitude is to ask yourself "how can we make this work?" instead of stopping at "this doesn't work because X". Propose things even if you can see they don't completely solve the issue. This fosters a collaborative building attitude where you can fill in your teammate's blanks and vice-versa. Simply stating what doesn't work shuts down idea sharing and limits the team's creativity to that of the individuals, instead of the (oftentimes much greater) sum of the team. |
I used to be hypercritical in code review, but I started instead just taking note of small things that didn’t really matter and fixing them myself during downtime.
I feel a little mixed on the solution. On the one hand it has the junior devs less afraid of me and more willing to actually ask for help. On the other hand they’re not learning from some of their mistakes. Life is full of trade offs though.