Feedback is an essential part of any software development project. It helps you improve your work, learn from your mistakes, and meet the expectations of your clients and users. But not all feedback is equally useful. How can you make sure your feedback is relevant, constructive, and actionable? Here are some tips to follow.
Before you give or receive feedback, you need to know what the goal of the feedback is. Is it to check the quality of the code, to validate the functionality of the features, to assess the usability of the interface, or to verify the compliance with the requirements? Depending on the purpose, you may need different types of feedback, such as code reviews, testing, user feedback, or client feedback. You also need to know who is the best person to provide the feedback, and what criteria they will use to evaluate your work.
Feedback holds significance across various facets of life, including software development. It plays a pivotal role in areas such as code review, client feedback, and UI/UX evaluation. Whether in possession of feedback or seeking it, its value is paramount. Every feedback exchange, whether given or received, should be driven by a clear purpose: advancement, improvement and enhancement.
Feedback should be as specific and timely as possible. Avoid vague or general comments that do not point out what is good or bad about the work, or what needs to be changed or improved. For example, instead of saying "The code is messy", say "The code lacks comments and indentation, which makes it hard to read and debug". Also, give feedback as soon as possible after the work is done or delivered, so that the feedback is fresh and relevant, and the changes can be made quickly and easily.
Delayed feedback loses relevance and impact, still it's useful if it is actionable. Vague feedback isn't actionable. Frame feedback using "I" statements to take ownership and avoid sounding accusatory. Instead of saying, "The project timeline wasn't met due to poor time management," you could say, "I observed that some tasks took longer to complete than anticipated, which affected our ability to meet the project timeline."
Feedback should be about the work, not the person who did it. Do not make personal attacks, judgments, or assumptions about the person's skills, intentions, or motivations. For example, instead of saying "You are lazy and careless", say "You missed some important details and errors in your code". Also, do not take feedback personally, but as an opportunity to learn and grow. Do not get defensive or angry, but listen and ask questions to understand the feedback better.
Feedback should not be only negative or only positive, but a balance of both. Negative feedback helps you identify and correct the problems and weaknesses in your work, but it can also demotivate and discourage you if it is too harsh or frequent. Positive feedback helps you recognize and reinforce the strengths and successes in your work, but it can also make you complacent and overconfident if it is too flattering or frequent. Try to give and receive feedback that highlights both what is working well and what can be improved, and use a respectful and supportive tone.
Feedback should not only point out the issues and gaps in the work, but also provide suggestions and solutions on how to address them. For example, instead of saying "The feature does not work as expected", say "The feature does not work as expected, because the logic is flawed. You could try to fix it by changing this line of code or using this function". Suggestions and solutions help you make your feedback more actionable and helpful, and show that you care about the outcome of the project.
Feedback should not be a one-time event, but a continuous process. After you give or receive feedback, you need to follow up and follow through on the feedback. Follow up means checking if the feedback was understood, accepted, and implemented, and if it had the desired effect. Follow through means making the necessary changes, improvements, or corrections based on the feedback, and documenting and communicating them. Following up and following through help you ensure that your feedback is effective and impactful, and that your project is on track and on quality.
Only partially implementing feedback without fully addressing the issues raised and not explaining the issue in non-technical mode, which can result in recurring problems, that is quite common. Any issue should be documented to test whether it covers the full use case, otherwise, the bug is reopened in newer versions and causing the trust to go down.