Software engineering depth combined with a business mindset and product view. Digging deeper, asking questions, focusing on what matters. Most work doesn't need that. Some work needs it badly. I offer services built around this experience and approach. rkochanowski.com/

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?