Seeking Advice to Improve Diff Quality and Efficiency in PHP Codebase

This is one of the examples of classic Meta culture shock, so don't worry, many engineers have gone through this before and successfully come out the other end (I mentored many engineers through this).

Your teammate is right in that your diffs are too big. The good news is that once you start pushing more atomic diffs, you'll almost certainly find all of these code quality problems going away. Your overall strategy here should be to:

1. Decompose every task/project you get into tiny chunks where each chunk is 1-3 diffs
2. Get feedback on your decomposition before writing any code
3. Execute and push out super clean, focused, and relatively small diffs

I made an entire course about this process (and more) which you can go through here: [Course] Level Up Your Code Quality As A Software Engineer

If you're crunched for time, you can start straight at the "Break It Down" section: https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/break-it-down/

As for specific tips on transitioning from Java to PHP, I unfortunately don't have much. I also joined Meta with a Java background, but I didn't have to write much PHP as I do Android. Java and PHP are pretty different languages, and to be 100% honest, I think PHP is sort of a janky programming language. My advice is to be a feedback sponge in code review, identify patterns from experience, and just keep on improving. More thoughts here: "What is the effective way to understand new repository in order to make the required changes in that repo?"

This is not specific to the Java --> PHP transition, but my recommendation with any new language is to make many small changes. Try to make them independent of your main project, which will likely require larger changes and more thorough review.

Instead, make throwaway changes which are very small quality-of-life improvements, e.g. variable naming, fixing tests, etc. This has 2 big benefits:

1. Reviews will be quicker and easier. Getting the LGTM from your peers, even for simple changes, will increase your level of trust.
2. These small code changes will force you to read PHP code, which will make you a better engineer.

How to apply the 'one diff, one thesis' to improve code reviews?

I've noticed that my diffs tend to undergo several rounds of revisions, which not only delays their integration but also consumes more engineering time than I'd like.

Here’s what I’m considering to reduce the review cycles and improve my coding approach:

1. Reducing the Size of Diffs
2. Pre-Review Checks: -- Any suggestions here would be great

Since you just started, your reviews will be under a lot more scrutiny, which is good since it'll prevent you from merging in bad code or causing any incidents.

Your suggestions about how to improve your PRs make a lot of sense. Opening smaller diffs can actually get your code accepted faster. It can be intimidating for someone to open a PR and see that hundreds or thousands of lines were changed. They might decide to look at the PR later in the day because they don't have the time to give it a thorough review in the middle of the day. But, if they see a smaller change that only takes 3-5 minutes to look at, they will be way more likely to close that loop immediately.

For pre-review checks, this will be less about the semantics of the code and more about being on the right path. A small explanation or bullet points about what you intend to do in your code change can prevent you from going down the wrong path and wasting a lot of your time as well as your reviewers' time. It will also help grease the wheels and get your review accepted faster because the reviewer knows exactly what to expect in the code review. There's nothing more demoralizing than someone blocking your review because the implementation is completely wrong.