Understanding the code base, writing good code, and flawless communication with maintainer are the fundamentals of the open source work. Luckily, I work with some of very experienced people in Starchart project. I learned that work can be faster when managing the work efficiently. Here's my lessons learned.
Minimize your work scope
If the PR has thousand line changes, it takes a lot of efforts not just for the code writer, but also the code reviewer. Also it means more chances of breaking existing code base. So it will take more than a week to get merged after rounds of reviews and updates. The longer the PR is under review, the more the PR gets conflicts especially if the project is very active. You can write sub issues of a large issue to minimize the work. If some parts of the issue is not the core of the work, you can separate for later follow-ups. Any work should be planned to finish within a week as project or organization usually is run on a weekly basis.
Split large scope of work into different phases
Planning big work into multiple phases is not easy task unless experienced. But this is something that I learned in Starchart project. The experienced code writer plans multiple steps for difficult tasks. I have seen the experienced developers build skeleton code without, write comments to show the intention, and structure the files without functionality yet. You can still have good code review feedbacks based on the function flow. Then slowly build up each module or functions. This way the work can be processed faster as you don't have to finish a large module at once. Instead you can finish your function, get it merged, and work on next function. I know it's not easy to plan things if the area of the code is new to the code writer. But I think it's a great skill and it's better to practice now.
Plan future improvement instead of fixing everything in one PR
Often times you get a feedback to change something during the code review. That change request can be essential but sometimes it can be improved later. Then you can suggest that you will write another issue to follow up. This way you can avoid another round of review and keep your change scope as originally intended.
Conclusion
When I work alone, I only focus on implementing features and fixing bugs. But larger project with a team requires more than implementing code. Design the system, continuously refactor code for better maintainability, manage issues and review someone else's code. And this planning the work will make a better look of the developer. The work progress is fast and easy to review. This technique will be more obvious in real world projects if you see PRs from the experienced.
Top comments (0)