Fork me on GitHub
#jobs-discuss
<
2021-12-20
>
vemv13:12:21

This SaaS caught my interest, do you see your team using it? https://news.ycombinator.com/item?id=29623505 Looking back at various past jobs of mine it would have seemed a good fit - on a bad season PRs would pile up for far too many days without a reviewer

p-himik13:12:19

It seems to me that it's more of a process problem than a technical problem. I.e. it would be better to prioritize code reviews correctly so that in-house devs do them fast enough so there's no piling up.

👍 4
vemv13:12:31

Yeah ideally there wouldn't be any form of outsourcing in a given company, but occasionally money can buy you the time 👀

rwstauner16:12:44

yeah, i have definitely seen PR's pile up for weeks (years), but in many (most?) cases i would think you'd need a lot of context about the system this PR is interacting with, and you'd get that much better from in-house people. this seems like a nice service for general programming tips... spreading the knowledge of how to do certain things well is great, but i don't think it would be sufficient to call the code "ready to merge" without a lot of internal business knowledge

rwstauner16:12:45

so i agree with the above statements, it would be better to work it into your company culture to prioritize reviews

Jivago Alves15:12:05

I hope my comment does not sound as “you’re doing it wrong” because you’re really not, however, after experimenting both options I’d give pair programming a try if feasible. For us, it has really helped to solve the main problems related to PRs and by definition people will have to understand and share knowledge about the business as others have said. The code review will be as good as the context the reviewers have about the business.