@djumaka@phpc.social what exactly do I check during a code review Ideas: If you're doing this in a business context, we find it helps to reframe this from "What do I check?" to "What must I cause?". Make it a discovery conversation, a don't-know-you-don't know conversation, a breadth-first conversation. For anything complicated, save negotiating solutions and fixes for a separate convo. Avoid rat-holes. It helps to drive it systematically by considering required questions to ask, which can vary depending on what the code is for. But a common list is something like: What problem is the unit/patch built to solve? What does it leave undone?What (in the design or implementation) creates risks to safety/security/privacy?What creates risks to maintainability? Does it introduce new dependencies sensibly?Does it conform to applicable specs/standards/regs?Where does it misunderstand/abuse its interfaces?Who needs to review this to adequately cover these questions? Who isn't here?