The bootcamp you are doing is a bit more advanced than our normal selection bootcamp. The reason for this is that we know you have skills, and we’re sure you have been maintaining those skills. This bootcamp will cover a bunch of things you are expected to already know.
You will also be expected to demonstrate a few extra “soft skills” as you go through this thing. Mainly you will be expected to be able to read and understand other people’s code, and you will be expected to communicate effectively about code.
You will also be expected to practice some of the good habits necessary on high performing dev teams.
On high performing dev teams, code review is a higher priority than writing code! When a dev team is slow with code review then they tend to just trip over each other and spend way too much time waiting and nagging each other instead of making progress. By prioritizing review, we prioritize real growth and progress.
In other words: As long as there is code that needs review, your top priority is reviewing code!
When you start work for the day: Do all your code review tasks, and then move onto writing your own code and doing your own projects. About half way through the day you should check if there is more stuff for you to review before continuing with your own projects.
We will be tracking this. We need to see some high quality work!
As you get started with Tilde, you wont have anything to review. You’ll see a bunch of cards, and those cards will see that those cards all have your email address listed under “Assignees”.
If you are the reviewer for a card then:
If you don’t see any cards that you are meant to review, then don’t worry about it. We want you to get into the swing of things before we ask you to review anything.
If you don’t have anything to review right now then feel free to finish reading this document later. But please note that it is CRITICAL that when it comes time to review code, you do a damn fine job!
There are 2 different kinds of code review you can do. Pull Request reviews, and Competence reviews.
In both cases, when you do the review you need to know what you are looking at. Make sure you are familiar with the project instructions for the card you are reviewing.
Look for yellow cards in the “review” column. These cards require that you:
If you see a yellow card in the “In Progress” or “Review Feedback” then the card assignee will likely be creating pull requests on the repos for those cards.
It is YOUR responsibility to keep an eye out for pull requests (PRs) on those cards. Sometimes that means clicking on the cards and looking at the repo.
If someone emails you and asks you to review their work, it is very important that you get it done. They are waiting for you.
You can also use this url to help make this easier:
https://github.com/pulls?q=is%3Aopen+is%3Apr+archived%3Afalse+umuzi-org+sort%3Acomments-asc
This page lists all the repos associated with Umuzi that you have access to. You’ll notice that there is a little blue highlight on the left of certain PRs. If something is highlighted it means that it has changed since the last time you looked at it. So you should open it up and deal with anything there that you can help with.
If you are spending more than 2 hours per day reviewing other people’s work then something has gone wrong. Let a manager know that you have too much code review to do. Once you hit the 2 hour mark, you have done enough and you should focus on your own code.
If you are asked to review a project and you simply do not have the skills to do a good job, then rather review the things that you can review well.
If all the cards needing review are above your skill level then you are going to need to work very hard to level up! You need to be at a level where you can do a good job on all the stuff we are sending you.
That’s actually ok. We don’t expect perfection immediately. Just do your best and keep your eyes open. Pay attention to reviews made by other people. Try to learn from the reviews you see.