onion2kMar 17

But you can’t just not review things!

Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. The remain 10% of things like var naming, whitespace, and patterns can be checked with a linter instead of a person. If you can get the team to that level you can stop doing code reviews.

You also need to build a team that you can trust to write the code you agreed you'd write, but if your reviews are there to check someone has done their job well enough then you have bigger problems.

Show threadSwizecMar 17

> You also need to build a team that you can trust to write the code you agreed you'd write

I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks”

Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for.

The other side of this is building safety nets. Takes ~10min to revert a bad deploy.

Show threadherbsteinMar 17

> I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks”

That's cool. Expect to pay me for the availability outside work hours. And extra when I'm actually called

Show threadSwizec

> Expect to pay me for the availability outside work hours.

We pay people enough to care about the software they ship.

Don’t want to be called outside of work hours? Make sure your code works. Simple.

Mar 17 at 2:12pmWeb