...
Noticing lots of back and forth on a few complex tickets (LF-2800 and LF-2801 in particular). What can we do as a team moving forward to try and minimize the amount of re-work? In particular I think there’s room for improvement around “tribal knowledge” like unit displays, systems of measure, display patterns, etc. that aren’t yet known to new team members.
Suggestions:
Heavy on pair programming to start
Small tickets to start
Focus on their strengths with slight expansion into areas they aren’t familiar with (e.g. if they are strong on BE, give them a ticket that’s mostly BE with just a little FE component)
Find out who knows a particular thing before diving into a ticket and connect with them
Doing a 1-hour code review of the app the first week, for example with Redux saga looking at containers and components
Feedback on hiring process
How is everyone feeling about the change from two reviewers to one?
. Carolina di Lello (Unlicensed) and David Trapp do you feel like your time was appropriately used in the interviews?
The assessment should be changed a little bit. Needs some more work on the back-end as well. Should also add a new table and do a migration.
How is everyone feeling about the change from two reviewers to one?
Start doing | Stop doing | Keep doing | Shout outs |
|---|---|---|---|
|
|
|
|
Action items:
- Carolina di Lello (Unlicensed) to add a few screenshots of unit displays and a link to Figma in action to the Unit displays write-up
- Lite Farm to modify the technical assessment to include some work around the back-end and a modification of the database, including a migration.
- Lite Farm to propose incentive tiers for contributors