Giving Feedback
January 07, 2026
Group meetings, 1-1’s, code? For the practice of software engineering, I want to give share my current thinking on feedback. It’s a different perspective than a year ago and I’m sure it’ll evolve more in the future. All those venues are different - words will be different and the impact of feedback would be different but the overwhelming approach is still the same. They require context - considered, validated context.
When I’m being involved to give a perspective on something - a presentation, someone’s performance, implementation of a specification - I tend to blinders on! Shocking to those that know me, but I can’t help myself but zone into what is being said and my brain refuses to zoom myself out. By default I focus in on the details instead of staying at the right level of context. So knowing my default is to get into details, how can I ensure that I stay at the right level of context to provide maximum feedback? (I keep finding new ways each day!)
Biggest tool is preparation. Unexciting I know but a big part of being successful is doing the hard work of being ready. Group meetings and 1-1s - take 15 minutes (at least) before each to figure out what is going on and what needs to get discussed. I have a standing Monday morning time block to look through my calendar and prepare agendas; I also do this every morning. For code I setup PR templates with the team, make linking to tickets automated, and ensure clarity in issue, resolution, and reproduction in each ticket. Preparation is much earlier for code. But when I get dropped into a random meeting - it’s okay to raise your hand and ask for clarity. What kind of feedback are you looking for? I’m new, can you help me understand if this is a recurring issue? Can we take 5 minutes and read through the material first?
I didn’t use AI for this, but did plug it into a word counter/spell checker. 2 wordsmisspelled