Giving & Receiving Feedback In A Team.
In software development, working in teams is inevitable for big and complex applications for various reasons. These range from the fact that it would take ages for one to handle on their own to the fact that it would have a lot of bugs. So working in teams helps regulate these shortfalls.
The biggest advantage for the developers is that their code improves through both seniors’ and peers’ review of the code. One can never get away with doing mediocre work this way.
At Andela, during the deferral program, I am a member of team Acqua where as we worked on a project called Authors’ Haven, the teammates and the Technical Team Lead review code to be able to merge foolproof code. I have got all the feedback that makes you cry while you fix changes, as you chew on a full bucket of popcorn at 2, am in the morning. It's not that bad though because the following time I become more careful on what I commit and push.
Below is an example of ASK kind of feedback ;
As you can see, I didn't just take on the feedback, defending what I knew and enquiring more on why I should drop my practice for their recommendation. In simple terms the pros that superseded my practices’ pros.
On finding the proper reason for their recommendation, I went ahead and fixed my code and I can gladly say its better state. Nevertheless, since we were all new to giving professional feedback, there are some reviews that were given that weren't Actionable, Specific and Kind in nature for example.
Well, sadly that's me giving that review before having any idea of what I should follow . This feedback was more attacking someone instead of helping them improve and ever since then I have come to give reviews that help others improve in a nice way also as illustrated down below:
I think here, there’s a great deal of improvement I inspired through suggesting an alternative and also adding why I suggested it.
Thank you.
