As a professional software developer, a big part of your career progression will involve how you work with others. Growth inevitably involves leadership. Even if you don't go into management, as you grow into more senior roles you will be expected to mentor more junior members of the team and help them to build a solid foundation of the fundamentals.
Learning how to give and receive feedback in a team environment can make a huge difference in how well you perform at a job and what you ultimately get from the role. These are my tips and insights based on my nearly two decades of experience.
Common Formats
As a developer, there are a few scenarios in which you'll find yourself either giving or receiving feedback. You should have a basic understanding of these scenarios so that you can be prepared with a mental playbook to help you navigate each situation.
Demos
A very common scenario in which you'll be receiving a lot of feedback is during a software demo. The feedback you'll receive during a demo is generally more of a functional nature, but depending on the audience you may be prompted with some questions on technical implementation details.
When you are giving feedback during a demo presentation, it is critical to remember the following:
- The team has worked hard to get to this point. You don't need to sugar-coat everything, but acknowledging the work that has been put in to prepare for a demo before you begin more critical discussion can make the feedback much more palatable.
- You also need to understand the scope of the demo. Details are important, but if there is a full agenda then it may not be practical to analyze every single aspect of a feature or address every thought that comes up. Take note of discussion items for later and keep things moving along.
When you are receiving feedback during a demo presentation, keep the following in mind:
- Business partners and various stakeholders generally care more about the results than the technical details. Keep this in mind as you present. Don't get lost in acronyms and that type of thing. Assume a low level of technical knowledge from your audience and you'll generally be safe.
- Remember that you're delivering a solution to somebody's problem. Software development is an iterative process (even if you're using a waterfall methodology), so don't take it the wrong way if you are told that the nice, shiny thing you just built doesn't do what it needs to do.
- Ultimately, be open-minded and you'll be just fine. Remember, you're one team working toward one goal and feedback is a natural part of that process. Even if it feels uncomfortable to receive it sometimes, it is ultimately for the best.
Code Reviews / Pull Requests
Code reviews are becoming more and more common these days. Thanks to tools like Git (and GitHub), developers have become accustomed to having their code analyzed before it is actually committed to a repository. The benefits of this, if not obvious, are that your code base stays more secure, consistent and accurate over time.
The last several teams that I've been a part of have required two reviews on virtually any commit, and have generally expected team members to review code multiple times per day. If you haven't already run into this scenario then you likely will in the near future.
When giving feedback during a pull request or code review, remember the following:
- Code is not the ultimate deliverable. I have seen far, far too many developers who get too caught up in the technical details of a problem and forget that we are ultimately part of a business and the main job is to actually deliver features with the smallest amount of code that is practical. Ask yourself if every piece of feedback that you plan to give is worth the time that it will cost, and try to use restraint in general.
- The code is not owned by one member of the team. I have also seen this happen too frequently where a gate keeper emerges among the team. He or she will be the first person to leave feedback on a pull request, and they'll faithfully have something to say on just about every pull request. Often times these folks give feedback in a way that sounds more like a list of demands than constructive feedback. Keep team morale in mind as you navigate this process.
- Validate your assumptions and run the code for yourself. I have also seen a fair number of developers who like to shoot from the hip when giving feedback during a code review. They'll tell you to change small things here and there, and then when you go to actually make the change you realize their suggestion just didn't work. The onus is on the giver of the feedback to ensure that what they are saying is actually valid and valuable, not the other way around.
When receiving feedback during a code review, the following tips will help you get the most out of the experience:
- This may be your only chance to get it right. This feels like the counterpoint to "code is not the deliverable" from above. They both get at the core issue of perfectionism and how it can often get in the way of "good enough", but at the end of the day you should strive to achieve the highest quality you can in the time that you are afforded. Different organizations will have different philosophies on how much time can actually be put into the craft of coding versus just delivering solutions.
- Look for repeating themes. Are you somebody who leaves a lot of debug code in your commits? Do you tend to skimp on things like unit testing? Do you even test your code changes in the first place before you push? Part of growth is showing accountability and taking your career into your own hands. If you see that the same feedback is coming up over and over again, make a special effort to address the areas in question. Spend an hour after work one night or a couple hours on a weekend trying to refine your skills and the growth you experience will be worth it in the end.
Regardless of the role you happen to be playing in each particular situation, keep in mind that the person on the other end of the interaction has everybody's best interest at heart. In these scenarios, we are all working together as a team for a common outcome, and so you should only ever assume the best intent on behalf of the other parties involved.
Day-to-Day Team Interactions
This is an area that I feel a lot of people miss out on. Even though you will find yourself giving plenty of demos and participating in hundreds or thousands of code reviews, there will be plenty of time in between those events. The majority if your time, in fact.
It is important to use this time to continue to seek feedback from others. Quick, informal sessions can be a source of some of the greatest feedback you'll receive because it tends to feel more authentic. By doing something as simple as dropping somebody a message to say "hey, let me show you something", you can really help to speed up the growth process.
You'll also find that there is a sort of "feedback muscle", and the more you exercise it the stronger it will become. This is what can take you and your organization to the next level.
Tips and Tricks
Alright, Tips and Tricks might be a bad heading for this section but I do have a few more pieces of general advice that I didn't have a better place for.
The first is to always understand that feedback is a good thing. If you view it as something complementary to the work you've already done rather than viewing it as criticism you'll go further with your projects and get there faster. Everybody is working toward one goal, and that must always be kept in mind.
It is also vitally important to remember the human elements in the process of both giving and receiving feedback. Be polite about giving feedback and gracious about receiving it. Remember that people will walk away from each interaction remembering how they felt, and that those memories will detemrmine the outcome of your professional relationships over time.
Conclusion
That's all I have for now! I hope this guide can help you navigate the world of professional feedback and give you confidence to move forward and become a better teammate! I wish you the best of luck and, as always, please feel free to leave me all your feedback!