𝗧𝗵𝗲 𝗥𝗲𝗮𝗹 𝗥𝗲𝗮𝘀𝗼𝗻 𝗬𝗼𝘂𝗿 𝗣𝗥𝘀 𝗚𝗲𝘁 𝗕𝗶𝗴
I once worked at a company that shipped massive pull requests by habit. One PR could sit open for weeks. Reviewing it required holding an entire subsystem in your head. Bugs piled up. Deadlines slipped. We eventually had to rebuild a huge part of the system because nobody could safely change it anymore.
The engineers were not bad. They were smart and worked hard. The PRs grew big for a boring reason.
Nobody taught them how to break the work down.
We often treat large PRs as a discipline problem. We say, "Just make smaller PRs." We act like willpower is the only difference between 1,500 changes and 150 changes.
It is not about willpower. Breaking big work into small, independent chunks is a skill. Most people are never taught it. When a ticket says "add billing," it feels like one single task. Seeing where one PR ends and the next begins is the hard part.
I used to ship big PRs too. I thought "done" meant solving the whole problem at once and sending it for review. It took years to learn that smaller is better.
Small PRs changed everything for me:
- Reviewers catch more bugs. A human can reason about 200 changes. They cannot reason about 2,000. They just skim and approve.
- Merges happen faster. PRs stop sitting in the queue.
- I stopped feeling overwhelmed. I focused on one piece at a time.
- I became a better planner. You must understand the shape of your work to break it down.
I started seeing systems as Lego bricks. They are small pieces that snap together. Once you see the bricks, cutting work down feels natural.
My current team ships small PRs. The results are clear:
- Our average merge time is 1.5 days.
- We find and fix bugs quickly because the changes are legible.
- Our delivery timing is consistent.
Breaking work down is a skill you must coach. You cannot fix big PRs with a rule. You fix them by teaching people to see the bricks.
AI makes this skill even more vital.
In the past, writing 2,000 lines of code took a lot of effort. That friction kept PRs smaller. AI removed that friction. You can generate massive changes with one prompt.
The effort did not disappear. It just moved to the reviewer. The author pays nothing, but the reviewer pays the full price.
ஒரு ஆசிரியர் எவ்வளவு வேலை செய்திருக்கிறார் என்பதை அளவைக் கொண்டு கணிக்க முடியாது என்றால், அந்த அளவு ஆபத்தைப் (risk) பற்றி உங்களுக்கு மிகக் குறைந்த தகவலையே வழங்கும். எந்தப் பகுதிகள் உங்கள் மிகக் கவனமான ஆய்வுக்குத் தகுதியானவை என்பதை நீங்களே தீர்மானிக்க வேண்டும்.
உங்கள் குழுவிற்கு நுணுக்கமான அடிப்படை கூறுகளைக் (bricks) காணக் கற்றுக்கொடுங்கள். பொறியியலில் (engineering) இதுவே மிக அதிக பலன் தரும் பழக்கமாகும்.
எந்தெந்த PR-களுக்கு ஆழமான ஆய்வு (deep review) தேவை, எவை விரைவாக அங்கீகரிக்கப்படலாம் என்பதை உங்கள் குழு எவ்வாறு தீர்மானிக்கிறது?
Source: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
Optional learning community: https://t.me/GyaanSetuAi