Arpit MohanTL;DR style notes from articles I read today.
Code reviews at Medium
- When making a change that affects the UI, include a screenshot, and preempt questions.
- Add a description of why the change you made was needed.
- Encourage quick reviews (at least one person responding within 4 hours).
- Build in small increments and request small PRs to move faster.
- Promote a ‘safe to try’ culture where developers feel free to make a call on which approach of solving a problem they take.
- Code reviewers don’t act as gatekeepers. They act as enablers.
Full post here, 5 mins read
How to be a better code reviewee
- Write tests before committing the code. Submit code and then test it together for review.
- Use descriptive commit messages. Group similar changes with a description for each group.
- Limit the code to review so that your reviewers are not too overwhelmed and have time & patience to consider the logic & depth of your code.
- Don’t take comments personally. Provide resources and arguments to defend your choice if you believe you are right.
- Take difficult problems or conflicting views offline. You will achieve consensus faster by discussing in person than over comments.
Full post here, 5 mins read
Just keep coding! - A letter to junior developers
- Develop the willpower, voraciousness, and ambition to learn more and the willingness to go the extra mile.
- Building a solid developer career is not easy or quick but the three most important factors are in your control: self-motivation, self-discipline, and focus.
- The beginner stage is hard in terms of getting, retaining and understanding lots of information every day.
- Enjoy the process, rather than focusing on the results.
- Plan first, then code. When working on a problem, think of the different ways to solve it and don’t just go with the first solution you think of.
Full post here, 5 mins read
