A continuación, te explicamos cómo puedes proporcionar comentarios eficaces sobre el código de programación de tu colega.

Principalmente sigo dos reglas a la hora de realizar comentarios sobre el código de otra persona. - Siempre en tono constructivo. Estamos aquí para mejorar y aprender. - Ponte en su lugar. Aporta como te gustaría que lo hicieran con tu propio código. La persona a la que ayuda a mejorar hoy es la que te puede ayudar a ti a mejorar mañana.

Rather, you can insert the comments on each and every place. So that, people can easily understand things you have done in code.

Code Review feedback should focus on code modularity more which often gets neglected. Including logic of multiple functionalities inside one method is never a good practice and should be avoided. Code segregation and giving your code a structure is the best practice and while analysing or giving the feedback this should be focused along with other parameters.

✔️Begin with positive aspects to set a constructive tone. ✔️Be specific about areas needing improvement. ✔️Offer suggestions or alternative approaches. ✔️Provide examples or code snippets to clarify points. ✔️Encourage open dialogue and questions. ✔️Focus on the code, not the person. ✔️Use respectful and professional language. ✔️Offer support and assistance for implementing changes. ✔️Follow up to ensure understanding and progress.

Code reviews should be a regular part of a developer's workflow and should not be looked upon as a negative critique of the accomplished work. Setting this baseline from the beginning of the project is vital. Moving forward all criticisms/advice should be constructive and specific. Providing details as to why there is or could be an issue with the current method and offering ideas on improvement.

In programming, feedback on code should consider the bigger picture—project goals, design decisions, team dynamics, and trade-offs. This ensures that feedback is constructive and aligned with the project's objectives, fostering a culture of continuous improvement and enhancing overall code quality.

Whenever possible, back up your feedback points with links and learning resources to help them understand the reason behind your suggestions during code reviews, for example. Being transparent about your motives encourages communication, growth and critical thinking in the future and it keeps discussions to a professional level.

To provide effective feedback on your colleague's programming code, start by understanding the context and goals of the code. Provide specific, actionable suggestions rather than vague criticisms. Focus on the code's functionality, readability, and adherence to best practices. Use a constructive tone, emphasizing areas for improvement and offering potential solutions. Encourage open dialogue and collaboration, seeking to understand your colleague's perspective and reasoning. Ensure your feedback is respectful and aimed at improving the overall quality of the code.

When pointing out issues, be as specific as a GPS coordinate. Don’t just say, "This looks weird," point out, "This function could lead to a memory leak because..." It turns vague hand-waving into a clear signpost.

🔍 Be Specific Avoid vague or ambiguous feedback, as it can lead to confusion and misunderstandings. Pinpoint specific lines, functions, or sections of code that need attention. Explain the issue clearly, referencing coding standards, best practices, or performance considerations. Provide concrete examples or scenarios to illustrate your points.

One thing I find very frustrating when someone gives generic feedback on a piece of code or pipeline without even taking the effort to go through the code and trying to understand the logic behind it.

I've been told many times by a friend that my way of implementing this function was weird. It solved the problem but it was "weird". It took a long while, for both of us, to realize he meant the time complexity was not like what we were taught in class, and therefore my code would be disqualified by the professor. It's important to be specific I agree, but sometimes you need to argue about the problem to realize them, it's okay to be vague at first, but it's not okay to leave it at that. Always make sure both sides understand each other's point of view. Communication is key, just like a relationship.

Also it helps building the developers or team trust and self esteem. Ambiguous remarks could make them feel helpless and that the whole code is bad. Specific feedback, on the other hand, can motivate them to focus and learn to tackle that problem.

Programmers write thousands of lines of code. They often do not remmember the exact details of the program and use abstractions to build layer over layer. When discussing issues one must be very clear about what and where is odd. One should be percise and explain exactly what is the problem. 1.Which file/function/object is the problem? 2.What might cause an error? 3.What are the expected results vs the real results? 4.How do I recreate the problem/test? The more details are given, the easier it will be to adress the issue.

Asking "which specific problem does it solve" usually puts the discussion into the right channel. In the given example, which is not specific enough to my taste, I would go a step further and suggest a different algorithm to use.

Make bullet points with the steps you are pointing out. In my opinion, there is no better way to explain what needs to be done. ;)

When offering feedback on code, be specific about what works well and what could be improved. Focus on individual functions, classes, or methods rather than generalities. Highlight specific lines or sections of code where improvements can be made and provide concrete suggestions for enhancement. Avoid vague statements and provide examples or references to support your points. Clear, targeted feedback helps the developer understand exactly what needs attention and how to address it effectively.

If the problem is a violation of a more obscure coding standard, link the coding standard line. If the issue is more subjective, such as a name of a variable, suggest alternatives. Warning: these sorts of code review issues - I don’t like this name - are really annoying. What’s confusing to you may not be so to others. They are often seen as a micro aggression. If something is sub optimal, you might provide specific steps to improve. E.g. this loop could be exited early when this variable is X.

When providing feedback on code, maintain a positive tone to encourage growth and collaboration. Acknowledge the effort and strengths of the developer's work before suggesting improvements. Use words of appreciation to highlight what was done well and offer constructive feedback in a supportive manner. Phrase suggestions as opportunities for learning and growth rather than criticism. Emphasize the potential for enhancement and the value of iteration in software development. By fostering a positive and encouraging environment, you inspire motivation and confidence in the developer to continue refining their skills.

Una buena de manera de dar feedback constructivo sobre una contribución y también sobre cualquier tema, es utilizar la "técnica del sandwich" - Primero resalta lo que haya hecho bien la persona - En medio, comenta aquella parte que podría mejorar - Por último, vuelve a enfatizar otro detalle que haya hecho bien.

Important de se rappeler que le but de cet exercice est de réaliser un échange positif sincere et humble permettant aux personnes de co-construire le meilleur code possible à un instant t. C'est un échange gagnant(vous) gagnant(le collègue) gagnant(les projets actuel et futurs).

🌈 Maintain a Positive Tone Remember, the goal is to help your colleague improve, not criticize or demotivate. Use a constructive and encouraging tone, focusing on the code itself, not the person. Acknowledge the strengths and positive aspects of their work before addressing areas for improvement. Phrase feedback as suggestions or recommendations, not commands or criticism.

The whole purpose of feedback is to help your colleague improve their code, so it shouldn't sound like you hold them at fault in the first place. The feedback is always for the code, not personal. It is an opportunity to learn together as a team. Next, acknowledge their efforts, and also what they have done well, instead of just pointing out mistakes. This balanced approach helps maintain a positive approach and fosters learning. It's also important that you make them understand that it's okay to make mistakes as long as they take learnings from it, and the fact that even the most seasoned programmers have learnt from their mistakes to be where they are today.

Nothing good comes out of being harsh to your colleagues. If you're a senior, keep in mind you were also once in that position. Do not kill the motivation and the will to learn in others, specially when they already know they didn't do as well as you wanted them to do. Always try to inspire others to learn, and keep improving. Let your coworkers know they only made a mistake in this part and the rest is fine. The mind always focuses on the negative parts. Negative words. Negative behaviors. So make sure you let them know that even though they made a mistake, they did well in other parts. And if you can, also try guiding them in the right direction. Maybe all they need is a little help.

Keep the tone more like a cheerleader and less like a drill sergeant. A "Great start, but let's refine this part," works better than "This part is wrong." It’s like adding sugar to medicine; it helps the feedback go down smoother.

Positive feedback tones are important to keep your workers and colleagues calm. If you desire for them to raise issues or accept feedback, it must be a pleasant or atleast a non catastrophic event. If they are afraid of feedback, they will try to avoid it. Beyond this it is important to mention the positive things they have done. This both calms them down and reminds them to keep doing things they have already done well. It is just as important for them to keep doing things that they are doing well as it is for them to fix the things they are not doing well.

There is no "dumb" question! Remember that you were also creating your first "hello world" program far back. Be nice. As a wise man used to state: "kindness generates kindness"

When offering feedback, maintaining a positive tone is paramount. It's not just about pointing out flaws; it's also about recognizing strengths. By highlighting what's done well alongside areas for improvement, you create a constructive dialogue. This balanced approach fosters a supportive environment and makes recipients more receptive to suggestions. For instance, acknowledging a colleague's solid logic in a sort algorithm while suggesting ways to enhance its efficiency demonstrates a positive, encouraging attitude.

❓ Ask Questions Sometimes, the best feedback comes in the form of well-crafted questions. Asking questions can prompt your colleague to think critically about their code. Inquire about their thought process, design decisions, or alternative approaches they considered. This fosters a dialogue and helps you better understand their perspective.

Sometimes you are not aware about the full requirements and you are only reviewing pieces of it, so it’s better to ask questions like 1. Provide reference to the ADR so that you can understand which piece is being developed and the story behind it. 2. Why custom query instead of standard ORM queries and what performance it improves and which problem it is solving. 3. Ask if they have considered any alternative approach or solution they thought before finalising one and why they have chosen that.

Frame some of your feedback as questions. "What was your reason for using this approach?" invites discussion rather than defensiveness. It’s less of an interrogation and more of a friendly conversation about routes on a road trip map.

Ask questions to understand their approach and thought process- the "why" behind a logic. This helps you avoid assumptions, understand the full picture and shows that you value their thought process, and take it into account before suggesting changes. Next, asking questions to get to the depth of the code helps make the feedback process a fruitful dialogue rather than a one-way communication, fosters learning as a team which passes down in your institutional expertise.

This is the most important! Try to understand how the dev thinks and that will help you to give further context along the way. Also, it gives them a chance to present arguments to justify their code and maybe you can also learn something new.

Asking questions is a respectful way of discussing code someone else wrote. They likely thought about it for far longer than you. Personally I have found that often, they thought of something better than what I had in mind. Sometimes they were right and my critisism was wrong. This happens often when questioning a colleague with more experience than you or a colleague that specializes in a particular field. Other times it exposes the faulty assumptions they made. Once an assumption is exposed, often they know how to fix it better than you. They know this code better than you since they wrote it.

Instead of just asking, "why a particular data structure was chosen", do it suggesting an alternative. Especially if it is a simpler one. If you are wrong, you will get an explanation. If your peer overengineered something, they'll get to a conclusion themselves. Nobody feels like a fool in the end.

Ask questions before giving your straight forward correct answer... Sometimes the person looking for advice did not express itself correctly or maybe you did not understand it. Ask questions so you and the person are on the same page.

Asking questions is a valuable strategy for fostering collaboration and more profound understanding when discussing code (or other subjects) with colleagues. By inquiring about their decision-making process and the rationale behind their choices, one demonstrates genuine interest and respect for their expertise. For instance, asking about selecting a specific data structure invites your colleague to share insights into their thought process and considerations, facilitating a meaningful exchange of ideas. This approach promotes clearer communication and encourages mutual learning and growth within the team.

I have literally put “Hey I’m not sure how this is working - let’s discuss”. And then reach out to the individual. If it’s a big code review and that discussion isn’t immediately possible, I’ll proceed looking only for non subjective points (divide by 0, uninitialized variables, etc) I do try to read the original bug and the entire change before I ask questions. I wouldn’t ever ask an aggressive question like “what led you to choose this…” as it’s too close to “what were you thinking?” Which can be quite aggressive. Instead I’d be more curious “I find the use of an array interesting - this looked more suitable for a sparse data structure. I’d be interested in understanding this approach.”

🔧 Suggest Alternatives If you identify areas for improvement, offer potential solutions or alternatives. Share coding techniques, patterns, or tools that could enhance readability, efficiency, or maintainability. Provide code snippets or examples to illustrate your suggestions. However, avoid being prescriptive – allow room for your colleague to explore and learn.

I agree but I would not provide the full answer. Definitely offer constructive feedback and provide the means for your colleague to resolve the issue

When suggesting alternatives, it's important to include an explanation, a purpose, and level of severity for the change. For example, one may see a pattern of a developer choosing one control structure over others in many cases where they may not be the best option. Sometimes the performance may be worse, or the code style may be less consistent with the overall codebase. In your Software Development group's culture, a decision must be made on which changes are critical, and which ones are preferable. For example, one may suggest an alternative control structure, show the performance benefit via results, but note that the performance change in a given circumstance will not be noticeable, but it can in future instances, giving full clarity.

Always offer alternatives and not have them figure it out on their own. This is exactly why your review is important. If you think that datatype is wrong but working, offer an alternative. If you think caching this query is needed rather than going to the database on every call, give that recommendation.

When you spot a problem, also suggest a fix or a better approach. It’s like pointing out a pothole then showing a detour. For example, "Instead of using global variables here, how about encapsulating them in a class?" provides a constructive path forward.

Don't wait to come up with some "Perfect" solution or alternative to speak up what's on your mind. Let your ideas flow and with continuous follow up questions and back and forth answering, you both add to the pile of ideas that will eventually lead to the best results.

Suggesting alternatives oftern helps the programmer solve the bug. Inexperienced progammers may need some direction. Positive solutions often help as even just mentioning a data structure or algorithim may lead them to study it, google it or ask about it. A direction is better than no direction. They may reject your alternative for a better option, but it is best they choose rather than not know.

If you identify and bug, issue, mistake or bad code, suggest an alternative that showing that you experienced something like that and point to a solution that worked for you and, it is good to show why it works better.

Contributing alternative solutions when identifying issues demonstrates proactive problem-solving and a commitment to the project's success. By offering actionable advice for improvement, one empowers our colleagues to explore different approaches and make informed decisions. For instance, suggesting the implementation of a hashmap for faster access times presents a concrete solution that can enhance performance and efficiency. This constructive approach fosters collaboration and drives continuous improvement, ultimately contributing to the project's overall success.

A menudo al escribir código, no pensamos en la forma mas óptima de hacer una acción o simplemente se desconoce dicha manera. Por lo que sugerir una alternativa puede ayudar a mejorar la lógica o entendimiento de problemas a futuro.

🔄 Follow Up Feedback is most effective when it's an ongoing process, not a one-time event. Schedule a follow-up session to discuss the implemented changes or clarify any lingering questions. Celebrate successes and continue to offer guidance and support. Foster a culture of continuous learning and improvement within your team.

After the initial feedback, circle back to see how things are going. It's like checking in on a plant you've just repotted. Does it need more water? More sunlight? It shows care and helps nurture growth.

Feedback should initiate an ongoing dialogue. Offer to review your colleague's changes and provide further insights if needed. This follow-up showcases your dedication to assisting and ensures that feedback results in positive outcomes. It reinforces the collaborative aspect of programming within your team, fostering an environment of continual improvement and support.

A follow up means that the reviewer is interested in how things have gone down, and how well their suggestions have been implemented. Naturally, this leads to another round of discussion, which can also improve the code further. So do ask about the code you have reviewed in the past, to see how your suggestions have been received.

When you see something that someone else has written, and you are more senior to them in the engineering hierachy, then you have a moral duty to rewrite their code while leaving snipey commit review comments and swearing constantly under your breath. If you are the person who is being code reviewed, this is the only way to 'learn from the masters' and will help you build a thicker skin and do less wrong in the world.

Remember, code review isn’t just about correcting errors; it’s about mutual growth and understanding. Make it a two-way street where both parties can ask questions and learn. This fosters an environment where feedback is seen as a tool for improvement, not just criticism.

Pair programming is often overlooked or discarded by naïve managers as a waste of man hours. In reality it makes things happen faster, and more than twice.

Embark on a journey into space technology by immersing yourself in educational resources online. Explore courses on platforms like Coursera and edX, delve into textbooks and academic journals, and engage in hands-on projects with local astronomy clubs or robotics teams. Attend workshops and conferences to stay updated on the latest developments and seek mentorship from professionals in the field. Join online communities to connect with like-minded enthusiasts and exchange ideas. Stay curious and persistent as you explore this captivating realm of discovery.

Also, it's important when giving feedback, showing the consequences of the mistake or the impact that it would cause if not corrected. People need to understand that there is a reason for codes to be written in certain ways.

From a manger's perspective, effective feedback allows the team to understand what is required from them and why their proposed solution should or could be modified. A simple example: a low one-liner might be complicated for a new team member. A reminder that easy onboarding will help them too.