How can you effectively give feedback to a software developer?

before rushing for the flaws of the software developer you need to take care of those things first: 1- Read the documentation to understand the scope he is working on, we think we already understand the scenario/Logic but we are just assuming we know which sometimes makes it embarrassing or just makes the developer deviate from the road. 2- Be flexible with other`s points of view try to put yourself on others' feet, and understand their role/seniority level to illustrate the context of the feedback. 3- Show guidance than pointing out flaws, people always think others reviewing is something personal, but showing clear guidance about improvement as a suggestion is always better than pointing out flaws and requesting to change them.

As someone who has been a software developer and has been in the software space for over two and a half decades, I agree any feedback should be relevant and constructive. From my experience, software developers want specifics. The more detailed and insightful you can be with your feedback, the better they are able to address the issue at hand. Be candid about your expectations, and provide specific examples of issues that have occurred. Focus on the problem rather than the person. Software development has always been about iterative improvement. If you understand coding principles, that will also help you to communicate with software developers better. You will find your feedback to be a lot more effective, considering these factors.

Just be specific, provide specific feedback by pointing to the exact lines of code, features, or behaviors you are addressing. Specific examples make it easier for the developer to understand and act on the feedback.

I've found to be helpful is by clearly identify the specific aspects of the code or behavior that you are providing feedback on. Vague feedback can be confusing and less actionable. I also acknowledged what the developer has done well before pointed out areas for improvement. This helps maintain a positive and encouraging tone. Avoid using offensive language or making personal attacks, as this can hinder a positive working relationship with the developers. After the developer has had time to address the feedback, follow up to see how they implemented the changes. This helps reinforce the importance of feedback and shows your commitment to the project's success.

Before starting your feedback, it is important to understand the context of the entire work, this means that you must maintain close contact with your team, know what is being developed, and above all have good soft skills to be able to deliver your feedback correctly. More importantly, with all these points you can give more personal feedback to each employee.

This is critical. NEVER add any adjectives to the work of the person you are giving feedback to. Nothing is "ugly", "bad", "confuse", "poor", etc. Keep it simple and always use the requirements as your guide. More than 50% of the time, the bugs are usually happening because of poor documentation or wrong requirements. So keep that in mind when you are talking to the developer.

For context, I'm talking about feedback in the same team between peers or from lead to team members. Don't just throw feedback over the fence and walk away, work on being the best possible team together. The feedback should not only include WHAT should be improved but also HOW to improve it. For example, if a person does not write clean code, you should not tell them "your code is not clean enough" and leave it at that. Better explain why you see space for improvement in their code style (e.g. situations where it hindered readability) and then provide them with the book (in this case) or other resources. Then plan together how to integrate it into their workload. You could maybe commit to a weekly learning session or a teamwide book club.

Being specific always makes feedback valuable. Tell the person exactly what you think did or didn't go well and maybe a suggestion on how to improve it. Not saying vague comments like, "I think you did good/bad on this job".

Otra cosa que entiendo relevante es el timing. El feedback debe ser dado a tiempo y no esperar a que el empleado siga con una mala performance esperando que milagrosamente sea consciente de ello. Desde el inicio del proyecto las expectativas del cargo deben ser establecidas antes que cualquier feedback. Parece obvio esto que digo pero ha pasado que entran a proyectos, los ponen inmediatamente a trabajar y los introducen al proyecto sin ningun tipo de guía de lo que en realidad se espera porque todos tenemos visiones diferentes sobre ello.

This is generic feedback. While it is fine, you need to get feedback from people you trust, and ensure it is constructive. A good way to ask for feedback would be: [Person A], you seem like someone who would be a in a great position to give me feedback. I would appreciate if you could offer it in the form of. A. Something I did well B. Something I could improve on.

I usually do not apply the sandwich method because it makes the feedback less effective. It is better to provide a direct feedback with a supportive follow up plan in my opinion.

In my opinion, I am not a fan of the sandwich method, although it is sometimes an effective method but not always as the sandwich sometimes can be a double combo??! In my opinion, using a standard method is something vague as each human nature is different than the other each of us thinks in his or her uniqueness so each person should have his method in his feedback. In addition, It`s always about how you will demonstrate rather than listing items. In conclusion, There are a lot of methods for feedback but In my opinion, I prefer customization for each person as it shows effort and humanization.

At least 8 suggestions may be helpful: (1) Before giving someone feedback, get his permission by asking "Can I give you some feedback?", (2) Demonstrate by your words and actions that you have the person’s best interests at heart. (3) Keep it simple and direct. Reinforce the positives and be candid about what needs to be worked on. (4) Make comments about the process, not about the person. Keep it action-oriented and informational. (5) Share one or two suggestions on how he can do it better. (6) Focus on the future, not on past actions. (7) Before concluding, try to get him to agree to the recommendations given. (8) If needed, make an appointment to follow up.

Inviting the developer for their thoughts is vital as their opinions or suggestions can have a great impact on the effectiveness of the system. Effective sof-twear or system always closes the gap. The knowledge of the Developer and their input should not be taken lightly.

There is no need to be afraid of asking for feedback, as an employee you need to have confidence in your work, and especially to be sure that feedback is something extremely positive, fear of feedback is normal, but it must be overcome as your confidence grows in your job. Likewise, this applies to you as a manager, it is possible for you to turn the tables and ask your employee for feedback on the way you manage the team, this usually increases employee's trust in management and causes bonds to increase. Afterwards It's easier to give them feedback, and it also increases the chance that they'll ask for your view of their work.

Este paso es super importante. No se trata de tirar palabras al viento que queden en la nada. Sino especificar acciones que lleven a que el desarrollador pueda mejorar, acciones concretas, un tiempo definido para desarrollarlas y nuevamente juntarse a comentar sobre lo realizado nuevamente.

Acho que todo feedback para ser dado, precisa de ter um acompanhamento, o desenvolvedor, principalmente o iniciante, assim como eu, está prestes a errar e cheio de dúvidas sobre o que realmente desenvolver. Ent?o uma das coisas mais importantes é ter empatia, cuidado com as palavras que vai usar, uma comunica??o assertiva e n?o violenta, e além de tudo isso, pegar na m?o da pessoa e ensinar a forma correta de fazer.

After feedback, it is necessary to keep the person in the loop, maintaining constant follow-up of the situation only tends to give the developer more confidence. Not to mention the fact that giving this special attention tends to show confidence and make it easier to resolve the situation, especially in cases of junior developers.

I always take a few moments to discuss things like evaluating code with developers coming onto the team. It’s easy to take a review as an attack on the way you chose to write the code. We need to keep in mind that the code is being written for the client. It’s not “our code” or “my code.” This simple change in mindset allows us to see these reviews as an attempt to improve the codebase overall.

The best environment for giving and receiving feedback is within a relationship where trust and candor are the norm. Prepare now for the feedback you'll need to give for situations weeks and months in the future by establishing a psychologically safe environment for you and your colleagues. RELATIONSHIPS MATTER. If you intend to give feedback, you need to earn that person's trust. A great guidebook on this is Radical Candor by Kim Scott.

Regarding this topic (and how to have productive conversations in general), I can highly recommend the books "crucial conversations" and "crucial accountability" by Joseph Grenny, Kerry Patterson, Ron McMillan, Al Schwitzler and Emily Gregory.

In the company I work for today we have feedback and coffee, it's an excellent way to keep in touch with your employees, where you have a frank conversation about not only work problems, but also about the things that bother you on a more personal level. if you wish of course. This gives the manager an opportunity after your feedback about your work, team, how you feel about the company and your personal problems (Again, its not mandatory, only if you wish) your boss has the floor and trust to then pass on his feedback, facilitating the entire process. This creates a relationship of trust that is very important and extremely respected in the company. I recommend the system.