Reflecting on the last few weeks

Work has been a little crazy the last few weeks. A lot of tight deadlines, unexpected challenges and changes to stories mid sprint, a mound of PRs to review, the works. And to be fully transparent it has been stressful. But, if I allow myself to take a second and reflect a little on this time, the outlook changes (slightly) from something seemingly really negative to more positive. Despite the pressure and craziness, I am so happy about the things I’ve been exposed to and have learned as a result of these tougher times we've been faced with.

• I got to dive deeper into GraphQL and the Laravel Lighthouse package.
• Because of some really strange business requirements for a project, I've needed to really pull back the curtains to see what's going on behind the scenes in Laravel and learn more about the “magic” the framework provides. This "core diving" into Laravel has also helped me gain a better understanding of foundational PHP and OOP.
• I had the opportunity to work with Job Batching in Laravel for the first time which was an awesome experience.
• Went super deep researching how SQL Server handles whitespace during comparisons. ANSI/ISO SQL-92 specification (Section 8.2)
• Worked with more complex Eloquent stuff like working with Unions, withWhereHas, and a few others.

All of this new knowledge and experience because of a few hectic weeks. I'll chalk that up as a win any day.

PRs - Debugging while reviewing

I was working through a couple PRs this week that were meant to address some bugs that were reported and I found myself wondering if I was going about the review the "right way". For some context, something I've always done with PRs is debug the issue while I review. But is this the best approach or necessary? Is it a "waste of time"? Or, should I instead just simply be looking at the code to make sure there are no obvious issues, it follows our standards, etc. and merge it? Putting more faith in the dev that they did their due diligence and did a thorough job at debugging the issue? Part of me feels as though if I myself can't replicate the issue and understand its origin, I can't confidently approve the fix. In this particular scenario, two of the issues were actually related to bad data and not necessarily a code issue so we eventually opted for address the underlying data issue and to not push out any new code. But this question always comes up. How deep should we go when reviewing PRs?