A lot was written about feedback. One past employer even provided us a training about the art of giving and receiving feedback. For those like me who aim to use feedback to improve their products or themselves, it's worth being aware of its traps. I call it "junk feedback" and nobody, including dedicated training, warned me. Here, I share some situations from my experience when we can receive junk feedback instead of real one. Before taking action, it's important to understand the context of the feedback that was given. Then, even a junk one can provide valuable information. - "We were impressed with your experience, but..." you were rejected. The classic one every job hunter knows. But even honest and more concrete feedback that seems real can be junk. When two recruiters gave me opposite advice, I become more careful. Both were right, both advised how to perform better on THEIR interviews. - Most companies have some kind of evaluation process for their employers. Don't mistake "evaluation" with "feedback". When our co-worker says something about us anonymously, we don't know the context. This type of information can be more or less actionable depending on how exactly it's done. - Public evaluation. Imagine a whole team meeting when everyone says their opinion about the current team lead and about new candidates. Everyone in the same room. Nothing but praise. - Asking friends and family about a product we built is an obvious trap. But even feedback given by strangers can be junk. If we ask someone who is not in our target group, we can receive a bunch of ideas on how to solve their problems, which are not related to our product. This can be useful, but not for building a product to satisfy everyone.

Building the tool that uses embedding models to find the hardest-to-detect duplicated code was only one part. Now that I've benchmarked the models, we can get the most out of it. The results surprised me. rkochanowski.com/article/emb…

Last year I built a legal AI app. This article explains one solution that improved RAG in a difficult legal domain. I used the described formula again in my latest project, a code analyzer. rkochanowski.com/article/rag…

AI coding tools introduce duplication and everyone uses them, so code duplication should raise in general? My analysis didn't show any trend, but it demonstrated how wrongly this research can be done and how misinterpreted the conclusions can be. rkochanowski.com/article/ana…

Should you allow team members to interrupt each other's work, or ensure uninterrupted, focused work? I suggest taking a step back and looking at this problem from a different perspective. We know that uninterrupted work is good and frequent context switching is bad. We also know that interrupting your own work to improve the work of another team member is good, and prioritizing your own work at the expense of the team is bad. This issue provokes heated discussions, often leading to extreme opinions. In reality, both approaches can work, because it all depends on the team, individual differences between people, the problem we are solving, the specifics of the tasks, and the organizational culture. In this post, I try to look at the problem from the perspective of real teamwork, rather than a set of rigid rules. When I write about "teamwork", I mean performing work in such a way that the team as a whole delivers as many high-quality results as possible. This work culture assumes that everyone is partly responsible for the team and the common result. Individual results are secondary. If teamwork works, we don't need rigid rules. If someone's task depends on me (e.g., waiting for code review), I can interrupt my work to unblock it. But if I'm working on a key feature that the rest of the team's work depends on, I can be more assertive and focus on my task. Each time, I assess what effect my decision will have on the result of the entire team. This level of self-organization is difficult and rare, so establishing rules regarding team member responsiveness may be the right solution. If you would like to improve your team's self-organization, here are a few things to consider: - How are people assessed, e.g., during evaluations or feedback sessions? Does it matter what a person delivered on time or whether they helped others? We are good at optimizing our work in terms of the metrics by which we are assessed. - Are the team results sufficiently visible? My tickets are clearly visible, but the fact that I helped someone without bragging about it is not necessarily so. - Does the organizational culture and communication support this approach? If someone refuses to help me immediately, I don't take it personally because I understand the reason. - Are we aware of the differences between people? Some may be good at switching contexts but worse at working with sustained focus. Others may be able to work continuously on a task, but switching contexts is more detrimental to them. - Are the team's priorities and goals known and understood by everyone? - Do we know what other people are doing at any given time, and are we able to assess how important their tasks are in relation to the team's goals?