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 threadalkonautMar 17

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement.

If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation.

Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.

Show threadsodapopcanMar 17
Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.
Show threadalkonaut
The problem is that you can only meaningfully pair program with programmers. The people involved in architexture/design meetings might not be programmers. The questions that arise when 2 programmers work might not be resolvable without involving the others.
Mar 17 at 2:05pmWeb
Show threadpydryMar 17

Nonsense. I pair all the time with stakeholders. If you strip out all of the cucumber nonsense this is essentially what BDD is - fleshing out and refining specs by guiding people through concrete, written example scenarios.

I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?".

Or, people on a different team whose microservice talks to mine when debugging an issue or fleshing out an API spec.

It's true that this isnt possible in plenty of organizations due to the culture, but lots of organizations are broken in all sorts of ways that set piles of cash on fire. This one isnt unique.

Show threadnomelMar 18
you're missing the context of this thread. for the purpose of code quality/review, it can only work if the other person is a programmer.
Show threadpydryMar 18

I interpreted what they meant as "pairing doesnt work with non coders doing non coding design/architecture/requirements".

Not "pair programming doesnt work with non programmers doing pure programming" coz it doesnt make much sense why you'd even attempt to do that. They dont care and they will get in the way.