[hzia]

I love this! We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action

And build an experience that guides them through the PR instead of getting distracted by nit picks. I we can only go so much with GitHub UX (bar chrome extension), so we may just have to rebuild the entire thing in our dashboard.

Currently we include a loom video on every PR (if its a frontend PR) along with a unique link to our dashboard to review / approve credit budgets. But we should double down to give a potentially better PR review experience and take over the experience in the long term

[quadcore]

Amazing. Glad this inspires you.

Another idea, maybe your PR is just a hook with no code initially, and then once the process is done via your UI, the final PR is shipped out - or the initial PR is patched.

We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action

Absolutely, this is an entire experience to rethink. If they love the experience, boom, the way I see it, you made it. Because when you think about it, you are changing things (very) deeply. Everyone ever wanted the backlog to be outsourced. I used to say, "if only we had fucking debugguers" ; to take on those nasty bugs that are essentially just a nuisance for the bottom line of business.

However it's gota be a procress for it to work. Brogrammers are just gonna mess the thing up.

I was thinking, maybe have a link in the PR for a receiving programmer to take on the PR, and then, use emails to get the programmer in the dashboard at key moments (brainstorming here, can only guess the details of how your thing work). With a dashbard for management (probably you have that already).

Think Jira, agile, process, industrialization, linkedin skill, etc. Cause the way I see it, you cant do it if you dont do it with deep integration. Otherwise human will freak out a thousand ways. Maybe have 3 different PRs for one task, the engineer can quickly browse. I know it sounds crazy but you know how this works: work from the customer and backward. Wouldnt you love to have 3 PRs you can browse and say: combine this and that and this and we good. Just throwing ideas out.

Really love that startup your working on. It goes beyond what the eye can see. Companies are bad at managing software development, they always were. They dont understand they need engineers - and technicians. They cant tell the difference, they only see programmers. With your stuff, one can imagine a future where they understand that (theyd hire engineers internally, and have technicians outsourced). I dont know. Im dreaming and halucinating at the same time, but seems to me it goes in the right direction.

[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.