[quadcore]

Let me expand on the 3 PRs idea cause I explained it badly.

If I receive one PR and its not good then my dopamine system is gonna say: it's a fail. GitStart you failed me and now Im gonna have to tell my sociopatic boss that the PR was no good for such and such and such reasons. Awful experience.

If I get 3 PRs, chances are, one is gonna be good and then they never was a single fail. Or if none is good but a combination of them could be, again, way way less of a fail for the dopamine system. "GitStart, it rocks".

I think the key idea is definitely to ship a PR with no code. You redefine the whole freaking house.

[hzia]

Internally we are expanding ways in which we draft multiple PRs initially when new devs onboard and send the one with the best peer review approval

We could infant send all the draft PRs upstream. And as a senior dev upstream, you review and merge the approach that works best

It would be offensive for most in-house teams to try to give our duplicated work, but universities and bootcamps get students to learn by doing the same thing in parallel anyways

[quadcore]

I see.

May I be brutally honest with you? I mean this to try of being of some help (how many times I wished people would just tell me what they trully think, I cant count).

I think you are trying to do two things here.

Most developers are mediocre and always will be. They just cant be autonomous like that. Growing and nurturing talented junior devs is a whole problem in itself. It's chaotic. You could but then sell him to the client once you have one that working good with a client. And again, you wont be clearing a backlog, you are recruiting and nurturing a junior dev for a client.

On the other side, there is the clearing the backlog problem for which you can use mediocre programmers. They dont need to be juniors. They just need to be able to clear a task decently well once in a while. This however can scale big. Think about how coding is trending toward AI-generated code. Most of the menial tasks and bugs and unit tests could be done by less than good programmers as long as you have the UX/UI to paliate the fact they arent autonomous. And of course some of them would learn the craft doing just that, get plenty of stars on your platform and then get properly hired for 100k a year.

I clearly dont have your experience on the subject, Im just sharing my 2cs based on my experience. My instinct would tell me to focus on the client need to clear the backlog, without adding more human management. But only you know what it's worth.

[hzia]

I appreciate the candid honestly! Even though we are aiming to become a career accelerator for junior devs, not everyone is going to graduate right away. For some, just a few months of experience is enough but for others it can take years.

But at the end of the day, success for both devs and engineering teams (aka clients) on our platform depend on the PRs shipped. Which is why we focus all of our energy on the PR lifecycle. All key metrics driven from PRs (review cycles, time to merge, merge rate and so on).

By keeping laser focus to complete a PR, both parties win. Which is why we optimize for that first, and on top of that build further ways for junior devs to grow and teams to accelerate their velocity.

So if we need to add more human management to ship better PRs we do that. But later if solving a client need can enable them to write better tickets (which will facilitate better PRs) then we shift our focus to that.

[quadcore]

... without being told you're poluting the old one.