taylor-s

Retries are good, conditional on having a client-side circuit breaker that stops retries quickly when nothing is working. Otherwise, they are good in good times and bad in bad times.

Clever | Remote (US) or San Francisco, CA | Full-time

We are hiring a Senior Software Engineer for our Infrastructure team: https://clever.com/about/careers/senior-software-engineer-in...

Clever is a platform used by more than 65% of schools in the US to streamline access to technology in the classroom, making it easier for students and teachers to log in (SSO etc) as well as for teachers and school staff to set up accounts and resources for their students.

The Infra team is similar to what you might see as Platform or DevOps team: we build software (in Go) so that other engineering teams can deploy production-ready services without focusing too much on the details.

The company is remote but we do have an office in SF for people who prefer office work-style.

I'm not sure I understand how post-commit reviews handle the case when two people are both working on the same repository. For me, the reason to invest in testing and reviewing before merging to main is that once any person has merged, the rest of the team is subject to any issues in their code.

Nor do I understand the argument that delaying reviews lets a developer iterate faster. If you are going to continue iterating on your work without waiting for feedback, why does it matter whether the work is merged in already or still on your side branch?

Yep! Here's the AWS documentation about this feature: https://docs.aws.amazon.com/amazondynamodb/latest/developerg....