Ask HN: Why is local event search so bad?
2 pointsby dcraw2 comments
- Reviewing code is much less daunting
- Reviewers give more detailed feedback
- Developers get feedback on lower layers (such as model definition) before writing a ton of code that depends on it
- Reviews come quickly enough that developers don't need to switch to another project before continuing
It was a bit difficult to make this transition. We started out by explaining what we wanted to do (submit shorter diffs) and why, and people generally were on board. But most people didn't know how to do it. It's not as simple as submitting a diff whenever you write 100 lines of code, since the diffs need to be coherent. Here are some techniques we used: - Use feature flags to commit unfinished features to master/trunk without exposing them
- Submit model changes as their own diffs, then API changes, then UI changes
- As you work on a feature, pick out parts that seem ready for review, stage and commit them, send for review, then branch again from that point and continue working. This takes a decent amount of git-fu, so train folks accordingly.
Another thing to note is that our reviews are not at all evenly distributed around the team. We have a team of 13 engineers, and it's probably an 80-20 split—80% of reviews are done by 20% of reviewers
https://jasoncrawford.org/how-to-work-with-stupid-people