How do you get the most out of a small team with limited resources?
While many folks may think of this question in the abstract, as someone who has been the lead engineer in teeny tiny startups for the past several years, and worked in non-technical capacities at media startups before my engineering career, I've had more than a decade to find out.
One of the main answers to this question is to prevent mistakes from happening. When you have too much to do and not enough hands or funding to do it, one of the first things to go is code review. You gotta ship product, not just sit around and talk about it. While that is definitely the sentiment in many places, I can speak from experience that this will more than likely cost you more time in the long run. Using a PR template can help you catch mistakes before they happen.
Another big issue when you need to ship features faster than you can fix technical debt is that you don't really have much in the way of documentation. That means when you encounter a bug multiple times, you may not remember what you did the last time to fix it. Using a PR template, at least in my version, can help you quickly find the info you're looking for.
Finally, when it's all-hands-on-deck, no one has time for a code review. So instead of making code reviews occasional events, from the get go you ensure that code is not merged unless it's reviewed. It seems like it takes up time, but when you're not having to stop what you're doing to do a hotfix, you'll be grateful for these reviews, which can be handled easily via PR template.
So, without further ado, check out the PR template I've been using for years and help yourself. Everywhere I go, I introduce this template and folks often adapt/change parts of it to suit their organization. I've literally had folks fawn over what a great documentary tool this template is, so I hope y'all can enjoy it.
TICKET
Link to ticket goes here
WHAT THIS PR DOES
(Summary of the PR issue & fix -- specifically list the steps you took to address the problem, link to Jira or design. Ex: 1.) Added props, 2.) edited styles...)
HOW TO TEST THIS PR
(Explain how to test the new features added in the PR, for example: "When you click the new icon you should go to the next screen, etc.")
ADDITIONAL INFORMATION
(Optional section to add info if needed, such as: blocked, don't merge until something else is merged, hotfix, etc.)
MERGE ORDER
(Add details here on whether this PR should be merged before or after another PR, or if it is blocked by another PR, etc.)
WHAT DOES "DONE" MEAN?
This PR has been:
- [ ] linted
- [ ] tested
- [ ] functionality has been verified against designs or tickets
- [ ] commented / documented
- [ ] made sure you pulled latest, resolved conflicts & tested
- [ ] peer reviewed at least once
- [ ] reviewed again by someone else (could be current review)
Image courtesy Vijay Sridhar here
Top comments (0)