at jobs we rock at Quality!!! :-)
too much of one == less of the other
find a balance between both
Buddha: truth lies in the middle way
at jobs we rock at Quality!!! :-)
let's balance it with Quality
Require time (Time vs Speed)
produce Context Switching
Accept PR as is: do changes in another PR/ticket
delay changes as much as posible (Divide and Conquer)
if there's a problem between parts
it can become a 1:n problem ;-)
A conflict is solved faster when
reviewers (n) help the requester (1)
so: try to side with the requester (1) ;-)
reviewers should:
have a helpful mind/approach
always review with speed in mind
devise tricks to speed up delivery
the Broken
the Slow
the Ugly
their importance is in that order
several degrees of Broken
some are stoppers, some not
Trick: the more 'not stoppers' => more speed
so: aim for no stoppers
Broken When? : corner cases of slow % usage
trick: relax Acceptance Criteria, talk to PO
Talk and Agree: deploy now, fix it later
prove your point: provide a benchmark
Trick: the right questions:
can the change be delayed, i.e. done in another ticket?
Style guidelines help here
Talk, agree, delay changes when posible
Recommendation: try to avoid this argument ;-)
Always talk!!!
comment it in PR so others know
speed goes up +1
changes take time
it feels lots nicer if you offer help
Pair programming is Awesome :-)
Tricks