Varun Srinivasan
@v
we don't block on code reviews to ship something by default. but there are two important nuances to this: 1. post-facto code reviews, where people can give you feedback on improving something after it ships. this is good for more pendatic, stylistic or perf stuff. 2. requested code reviews, where people working on sensitive code know that they should ask for reviews. this happens often when working on security critical stuff.
6 replies
3 recasts
78 reactions
androidsixteen
@androidsixteen.eth
I can't tell if I'm a boomer and this is good for velocity, or if this is an anti-pattern that sacrifices long-term velocity / stability for short-term gains @giu and I review each others' code and we frequently catch things the other misses Especially as you scale the org, how do you prevent bugs from getting into prod?
1 reply
0 recast
1 reaction
pugson
@pugson
you don't. gotta fix them quickly
1 reply
0 recast
0 reaction
androidsixteen
@androidsixteen.eth
Thatβs terrifying
1 reply
0 recast
0 reaction
Varun Srinivasan
@v
when you start a new company, the cost of shipping a bug is near zero and the cost of not shipping the right feature is a few billion dollars.
1 reply
0 recast
2 reactions
androidsixteen
@androidsixteen.eth
5 years and countless features in, how do you scale a codebase that has an unknown number of issues waiting for you to uncover?
1 reply
0 recast
0 reaction