Launch HN: GitStart (YC S19) – Remote junior devs working on production PRs
We recruit devs who want to grow from remote countries, to work full-time on these tickets and review each other’s PRs. For tech teams it’s pay as you go, and they only pay if they merge the PRs (we pay our devs a base regardless). GitStart is very personal to me because I struggled myself to start my career as a junior dev. Being born in Pakistan made it super hard to find my first remote job. Things changed with Google Summer of Code, which was the first time I got paid to contribute to a large production codebase.
When I became a staff engineer, I started mentoring junior devs on their solo projects. I then realized what they really needed was production code experience, so I started sending them tickets from my backlog to grow them through code reviews. I also paid them for it. They learned a lot and I got a lot done, which started GitStart.
That’s why, in the description above, we say “devs who want to grow”. This is key to what we do—we are not just a body shop or middleman, and we don’t charge by the hour. We provide useful mentorship to junior devs. We want to be a meaningful part of their career path.
Our thesis (to use that slightly pretentious word) is that the economics work better this way as well. There is a lot of junior dev talent in these countries whose potential will bever be realized by hourly piecework. What’s needed are longer term relationships and work engagements, over the course of which a junior dev can learn and grow on a large production codebase. Much of this has to do with learning the culture of effective tech teams.
On the other side, effective tech teams don’t want hourly piecework either. Clients tell us they love having developers dedicated to their project, becoming more familiar with the code over time. This is the way for value to be maximized on both sides.
A number of commercial open source repos already use us, so you can check out some of the PRs created by GitStart here:
Cal.com: https://github.com/calcom/cal.com/pulls?q=is%3Apr+author%3Ag...
SourceGraph: https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+a...
StoryBooks: https://github.com/storybookjs/storybook/pulls?q=is%3Apr+aut...
Strapi: https://github.com/strapi/strapi/pulls?q=is%3Aclosed+is%3Apr...
Supabase: https://github.com/supabase/supabase/pulls?q=is%3Apr+author%...
Twenty: https://github.com/twentyhq/twenty/pulls?q=is%3Apr+author%3A...
Our main technical challenge has been securing code sharing. One solution was building GitSlice, which enables creating sub-repos that sync with the upstream repo. When GitStart devs create PRs on the platform, GitSlice syncs them upstream while pulling back CI/CD checks and review comments. This e...
198 comments
[ 3.6 ms ] story [ 236 ms ] threadWe have been able to eliminate a lot of un-usable PRs by having a very strong internal peer review and QA process. So PRs almost certainly works, and code review goes through at-least 2 separate reviewers
TBH, I think adding teachers that grow devs entirely through reviews is a great idea. We currently do give internal training and guidelines for reviewing PRs, but havnt gone that far yet.
At a lot of jobs I've dealt with using contractors, there was an internal concern that people external "didn't care" enough. How do you plan on addressing this concern?
It's a system that will depend a lot on trust, and it may be difficult to build that with companies whos DNA does not lend them to trust outsiders AT ALL let alone let them come in and muck with production level code (letting juniors do it!)
I'm playing devils advocate, like I said I think your idea is cool and worth exploring. Not enough companies invest in juniors to grow them into their full potential, and I commend you for this effort. Good luck.
While GitStart pays their developers, that alone could encourage better habits, I fear it could also enable this chasing reward mentality harder, setting the juniors up for failure, as well as frustrating the customer with having to deny and review multiple low-quailty PRs.
How is this avoided? This seems heavily at risk to cause more headache than help.
To prevent “Hacktoberfest” style PRs, we have a strong peer review system internally along with QA. Which is the reason why most of the above open source projects have found it a lot easier to merge GitStart PRs than the PRs by juniors posted directly
I do wonder though how we this problem can be solved for all junior devs contributing to OSS
That’s correct. Either you are a full time employee, or you get second-class culture even if you are part of internal slack. It’s very hard to get external contractors to be excited when they dont get the swag / on-sites and share the culture.
Which is why we want to have devs belong first class citizens in the GitStart Community, and join all hands / game nights and learn from others. And our integrations push through PRs and all the updates to engineering teams.
It’s not the lack of swag or on-sites. Companies usually outsource to cut costs, so there’s your problem. Also, I’m not convinced there’s correlation between being “excited” about a company and producing good quality results.
I was previously referring to the 'external "didn't care" enough' which is generally true, and IMO not an inherently bad thing on its own
But I am not sure outsourcing to cut costs is happening as much now than a few years ago. The entire outsourcing tech market is shrinking, as most teams prefer to keep devs in-house than to outsource it away.
From my experience hiring, both full-time employees and contractors can not care; it felt more about the individual's character than their employment status.
Also some cultures also show far less care than others (despite feeling the same way)
A lot of my Asian friends do not pro-actively jump into slack to not look stupid, but the moment you get on a pairing call with them the perception changes quickly as they are not as shy in a smaller group.
Yeah, I don’t care.
I don’t mean to be harsh, but if I have to justify spending my company’s money on this, this is definitely not something I’m going to say. This isn’t charity, and I’m looking for quality code.
Which is why we actively monitor review cycles as our biggest metric internally to make sure quality is solid across all active repos.
Thats why on our landing page, the focus is on the service itself with some mission interleaved. Would you reckon it's the right balance?
You gotta look at this from your customers’ perspective. All they care about is that using your service means quality work for less cost. The more you talk about other things, the more they’re going to question the quality of the work they get in return. So even though it’s a noble goal, I wouldn’t mention it at all to customers.
Where I would emphasize it is where you onboard devs to your platform, since they care about their own personal grown. Or when you hire people for your company, since people like working for a good cause. Or maybe if you’re trying to score some grant. Perhaps even some investors care, depends on the person.
But customers? Nah. They have other problems to worry about.
This sounds odd. Why just from "remote countries"?
Is it because they can be paid less than in not so remote countries?
Are you going to ensure that if someone from the UK hires such a service, the worker performing it will be paid at least the UK minimum wage for the time spent?
I have a feeling this is just another way to get cheap labour.
You make it sound like it’s a Bad Thing (TM). The apprentices that sign up for this gain real world experience that’s hard to come by locally and get paid for it.
This kind of extended apprenticeship is valuable as they can go on to land remote jobs that pay them better than their local market.
Perhaps they could have worded that more clearly as: “we recruit devs . . . from low-income countries with English as their official language”
This is how they are able to make the economics work.
EDIT:
https://www.pullrequest.com/ is a comparable service (where you involve “outsiders” with your codebase) except they use senior devs rather than junior devs. Of course senior devs are more farther along in their careers so it is clear you are paying for their experience.
Particularly after the publication of The World is Flat [1].
1: https://en.wikipedia.org/wiki/The_World_Is_Flat
Stretching this to the limit, it would be a "good thing" for me if there was a law saying that I specifically should be paid more than all others of equal skill, but (even if I could somehow lobby to legislate that) I think I would prefer to compete on my own merits rather than artificial limitations.
Because why would anyone in the west invest in education if employers are going to look for talent overseas where it is relatively cheap? Take on that student debt only to find you'll have poor chance repaying it, because the available jobs won't provide for the living you were looking for.
This is essentially "dumping".
It has a great potential for widening the social divide. Here in the UK it is illegal to hire an apprentice without at least paying them a minimum wage. The reason is that before the change, the apprenticeships were snapped up by people from wealthy background who could afford to work for "experience" or "exposure". This created a bubble, where at certain jobs you wouldn't see anyone from disadvantaged background working there, because those people had to take on jobs that weren't aligned with their interests, simply because they were poor and couldn't afford an apprenticeship. Now, the minimum wage thing is still not ideal, because in certain areas that's not enough, especially where you have a large family to support, but it is better than nothing.
A UK based, official Google Cloud partner was offering him £2.50 per hour gross for a DevOps position. Yes, £2.50.
I didn't believe it until he forwarded me their official offer letter.
I'm from a rather poor country, and when I was starting in my career I would absolutely love to earn $10/hour. In fact that would be a dream salary for me. $2.5 is not great, but it's about what I earned in my first job (and my country may not be rich, but it's still way richer than Ghana).
So I'm not sure what's wrong with that. Can our friend earn more locally? Great, they should reject the offer.
We have automated on-boarding flow only for JS / TS, but we in-fact support 15 tech stacks including React Native, .Net, Native Mobile & Django
Mobile is our largest tech stack after JS / TS because we were able to build review environment for mobile apps that make it drastically easier for junior devs to review and QA their PR before its pushed upstream without having the actual native device.
> One solution was building GitSlice, which enables creating sub-repos that sync with the upstream repo. When GitStart devs create PRs on the platform, GitSlice syncs them upstream while pulling back CI/CD checks and review comments. This enables our devs to contribute with limited codebase access.
Is this an internal tool or something you also make (or plan to make) available? We have this problem too at Ritza (a technical writing agency), where often our customers have a mono-repo with a docs/ subfolder that we need access too. Currently we solve this with some custom bash scripts and cron to sync just a subfolder to an internal copy, but is far from perfect and still involves some manual cherry-picking.
We go much further than CopyBara by syncing CI / CD pipelines, syncing review comments and so on.
We are considering launching GitSlice as product on its own. If you are interested, email me and I can keep you updated when its ready to test (hamza [at] gitstart [dot] com)
For example, in my first job, I was tasked with greying out a button after it had been clicked. Trivial and generic task. But I was paired with a brand new senior to do the work and we spent a day trying to find the correct button (being new and wanting to seem useful, we didn't want to ask).
It got a lot better with covid which started the wave of remote work and teams started to care about writing tickets for the first time.
Currently we solve it with ticket templates, but we are now doubling down on using AI to help craft and improve ticketing writing. It’s still under private beta, but will be live for everyone soon https://gitstart.com/changelog/tickets-by-chat
Do you mean your team? Because this would be an absolutely ludicrous thing to state generally.
> using AI to help craft and improve ticketing writing.
Right so speaking of AI, how do you plan to keep up with github copilot and how can customers be sure that you're not just using copilot under the hood?
In general, jr devs are net-negative. (If they're not, they're not junior! promote them!). They are an investment, they are learning and growing. It will take a senior longer to review, mentor, and coach them to a PR that the senior could've gone straight to that same PR. The whole point is that eventually you've grown another senior dev who will return big multiples on their compensation.
This sounds like you're just going to be spending sr dev time reviewing and rejecting, to have de minimis backlog items (there's a reason they're in the backlog and not prioritized) fixed, and you're not even growing a senior dev, which is the whole point.
Plus, IME most companies carry so much cultural context that being exposed to it for exactly 1 ticket + not having inside people to ask questions means this will be an uphill battle.
With GitStart, we take everything else away entirely (dev envs, preview links, mentorship, trainings etc), with strong processes to make sure PRs are heavily reviewed internally with solid QA before its pushed upstream. I think this drastically reduces cost of working with juniors to the point that its “profitable”
Right now it’s not for everyone, especially for companies where there not enough motivation internally to craft good tickets or having enough backlog thats critical enough to make use of GitStart.
Now everything aside, we actually have seen cases where devs internally grow within, apply to our customers and become full time hires! We dont bind our devs at all to join our customers directly and instead celebrate it when it happens!
"Plus, IME most companies carry so much cultural context that being exposed to it for exactly 1 ticket + not having inside people to ask questions means this will be an uphill battle."
I'm curious as to how you make this work when I'd imagine even a simple ticket for anywhere I've worked would go something like this: "first learn our monorepo, then learn how all the internal testing tooling works, and oops your PR is going to touch our in-house/NIH'd migration system. Also you can't just rename this db column, let me explain our db replication strategy (which you can't touch or observe since no way would a non-employee have any of our AWS access, even for dev). oh and Jim (haha good ole jim, he wrote like 40% of the code and then got fired after 2 years because he told the CTO to go fuck himself) wrote that code in a rush in the before times so it's creaky, try not to ever touch or look at it, so work around it in the app code even if you might otherwise want to change it" and so on and so on.
(I also find learning all this stuff - the NIH systems, the stack, who the Jim is this time around and what code he wrote, etc - is like 85% of the part of spinning up at a new company and it takes like 6 months of fireside campfire stories to pick up enough of the lore)
It sounds like a shop like this would basically mean devs are eternally in that "doesn't know about Jim's code yet" stage.
You are right, it will never replace good old Jim (or a backend dev). What it can do instead is to accelerate the devs. What if Jim created tickets to add a GitHub action to run linting on every PR, update and refactor existing code based on a new formatting rule, add more unit test cases? Basically utilize GitStart as a way to accelerate on tickets that may not be worth his time, but accelerate everyone else.
On a go to market comment, we are laser focused first to target frontend teams, particularly where as long as you have API docs (Swagger, GraphQL), and a staging environment (or we help create one) devs can go a long way without shared context.
Jim said we will add more bugs fixing it so we believe him.
On this page. The error is coming from your GraphQL backend:
{ "errors": [ { "message": "has invalid format", "path": [ "createDeveloperProfile" ] } ], "data": { "createDeveloperProfile": null } }
Thanks for the report. Turns out it was one of the Falsehoods Programmers Believe About Names[0] we'll deploy the fix in a moment.
[0] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
Is GitStart a significant pivot from what you started with?
The harder part was getting the system to work (aka ship solid PRs while delivering a good growth path for juniors).
Most of the time was spent building a ton of in-house tech (especially around security, dev environments, review environments and so on)
We are now in a better position to automatically onboarding engineering teams (and later this year do the same for devs to sign up and start to ship PRs on the platform)
I wonder if companies will double down on full remote or this will revert back slightly.
I love working with earlier career engineers but their code isn't known to always be very high quality. How does that work on GitStart?
We first got the more experienced junior on the repo review others. Later on, we started to enable multiple devs to work on the same PR initially, review each other and best one sent back
And with GitSlice, we have been able to take very large codebases and slice it to a smaller repo that is much easier for juniors to work on.
So now we get teachers and seniors to train juniors, but they are not in the loop of the PR execution anymore.
We are not fully there yet, but you can see from the Open Source PRs above that its good enough that this can make an in-house team more productive than the default.
Biggest part that makes it work are enabling multiple devs to review each other, solid QA and dev environments to reduce hand-holding and a community to grow and learn from.
Larger corps like Google already have this infra setup, but most teams cant afford to build it internally.
It got merged so clearly the devs find value in the work but I wouldn't call that production ready.
I talked to them about this and they said they'd work on it etc. etc. Not sure if anything has changed in that regard or not.
[0] https://github.com/streetwriters/notesnook
[1] https://developercertificate.org/
The problem lies in the definition that “committer most NOT be an organization” which would require us to do a full review of our legal contract with devs so that this condition is upheld properly
I'd really like an avenue to get into the US market as a remote worker, but am being unfairly treated by this job market. It is a pity as I am both a highly skilled programmer and have nearly a decade of experience. I'd consider this service if it could serve to showcase my skills, but if I am not going to get any credit for doing the work personally, there doesn't seem to be much point to it.
What would be an ideal way to attribute the hard work back to the devs in our case?
Depending on your location there may be legal restrictions preventing from US companies hiring you - even through a B2B contract.
But ultimately it depends on the motivation of the company itself, and they use all sorts of excuses to not work with non-US staff
The ones that care to hiring within vetted countries for $reasons usually will not accept exceptions. Notable example is GitHub which has a list of countries they hire from (even though they're owned by MSFT and could hire on the Moon if they wanted).
Having a company is mostly for tax purposes. It makes everything easier. I think the hiring company doesn't care if the contract is done with a business or an individual. Both are usually limited liability and offer no advantage in case of contract breaches.
In my experience as a hiring manager it was quite rare to see lots of OSS work in candidates’ GitHub accounts, but I’d absolutely prioritize those that had good work in OSS. (Also worth emphasizing that technical design, collaboration, and documentation are important and underrated, and can also be showcased in an OSS project. If you can demonstrate good communications in an async OSS environment, that would probably reflect well on your ability to contribute as a remote employee.)
All that said I’m not sure that OSS is the best resume builder. For big companies you need to drill LeetCode and system design. Perhaps for startups it is not the worst use of your time.
Exactly. Any hiring manager with a brain and not bound my clueless corporate processes would use OSS contributions are a decent signal for proficiency and social skills.
That means nothing in a big corp though. The hiring panel will never accept a candidate that fails the Leetc0d3 test because that means other panels could do the same and then it all falls apart for them. Status quo and all.
As a small company you don’t need to try to remove bias with objective metrics (indeed, “culture fit” and “thinks like me” can be good heuristics for building a small tight-knit and high-performing team) but when you hit the company size where you must introduce multiple layers of management, then fully trusting each line manager’s subjective judgements can lead to very disparate quality and other political/organizational issues.
Many companies, including my own and the commercial open source companies mentioned in this post, consider open source contributions a major factor in hiring remote talent.
In your experience, is there usually a more or less deterministic path to a stage where the question of starting to get paid usually comes up? Who initiates it?
The result of this discussion may very well be that the company isn't interested in this kind of relationship for any number of good reasons. But what's important, I think, is for a contributor to be able to have the right expectations coming in. As in:
- Should I join on a purely for fun basis and see where it goes from there, keeping in mind things most likely will stay this way going forward.
- Or if everyone is happy with the quality of code, communication, etc across a number of pull requests, then it's definitely OK and expected to bring up the question of payment/employment.
Thank you.
Send a couple more high quality PRs and you can likely leverage that into a job.
There is no deterministic way to transition from unpaid to paid. It's just one signal among many that a recruiter or company looking for services would look into.
We often think of orgs as these big trusty things but honestly they are just groups of individuals, and it's harder to trust N individuals than it is to trust one individual, especially when the N is opaque and unbounded.
What they should do is co-sign the PRs/commits so it's the worker's personal account + the GitStart account. Then the workers are actually building a git repertoire for themselves which puts them a step closer to independence. That might go too much against the exploiting cheap labor theme that seems to be lurking in the dark here though. That said, I would love to be pleasantly surprised if GitStart is OK with co-signing commits alongside accounts directly in the control of their workers. Would definitely be based, doubt it will happen.
On top of that, we are thinking about developer profile you can share as a part of your resume. I'd love to hear some suggestions on what you think we should include in it.
In general my advice is this is one of those gray area markets where it is extremely easy to exploit workers, so you should do everything humanly possible to make sure that:
a) workers in this program are progressing with the goal being they can eventually "graduate" to the point where a middle-man is not required. This won't be possible across the board but an evil version of this startup would be designed to keep workers in this situation as long as possible, so just don't be that.
b) Allow customers who want to direct hire specific workers to do so seamlessly and don't do hefty referral fees that are enough to stop a lean startup from being able to pull the trigger. I've personally witnessed startups unable to pull the trigger in such situations because they can't afford to "buy the person out" of whatever referral company owns them. Don't be like that. If you absolutely must do a referral fee, structure it so they at least get back the money in credits with your program or something.
c) Treat workers like the assets they are -- each worker that eventually gets a job through your program becomes a marketing asset that will drive referrals from their home country when they eventually find success and tell their friends how they succeeded. Make sure you have created a positive enough experience for them that they will actually recommend you and dear god give them referral fees when they send you someone.
That's my free advice
a) we already have a sizeable alumni who have gone through GitStart over time, with many still in touch. We are in works to bring them all together in discord
b) there is no current restriction or even referral feel for both devs and companies to work with each other. The only thing we ask is for devs to either be full time on the platform or work with them directly and pause GitStart
c) good people recommend more good people! And we have a program where as alumni they get free credits for their own companies (over 5 have launched their company and used those free credits)
We currently do not have a referral program for alumni to recommend devs (it is there for currently active devs) but that’s a great idea to roll out!
I read the certificate. It isn't long:
Where does this require that the submitter not be an organization? Even if you're fully committed to that idea, the obvious approach would appear to be:(1) GitStart releases their patch under the open source license of the project's choice.
(2) An employee of GitStart submits it, in their official capacity, to the project, asserting under clause (b) that the contribution is based on (consists entirely of) previous work that is covered under an appropriate license.
* "Do work, but get paid only if we use it" feels potentially exploitative. You do mention a "base pay" rate but I wonder how it compares to the "merged PR" rate?
* Code quality and adherence to internal code standards is challenging for external contributions. Open source projects, of course, are already used to this, so it's not surprising to see that's where the bulk of your current customer base lives; it's more difficult to see how this would work with other types of organization -- I'd be concerned that I'm spending more time in code review and such than I'd gain in contributed lines of code.
* The whole setup seems to fit in an uncomfortable middle ground between just hiring an offshore developer directly or through a traditional outsourcing firm, on the one hand; and hourly piecework on the other. The only advantage I see to this sort of arrangement on the hiring end compared to regular old long-contract outsourcing is that I don't have to pay for work I don't end up using, but that circles me right back to the "exploitative" part.
90% of compensation for devs is base and does not depend on the “merge PR” rate (which is in-fact 95%)
> * Code quality and adherence to internal code standards is challenging for external contributions
> The whole setup seems to fit in an uncomfortable middle ground
Majority of our customers are in-fact private and not OSS. We can unfortunately only share the latter. But it is targeted towards engineering teams that have already started to invest into DevEx and building tooling to make contribution easier We do help to set that up if customers sign up on the Team or Enterprise plan as a first sprint to add all these guardrails in place.
I agree that junior devs today are heavily exploited by existing freelance and outsourcing platforms where it's a race to the cheapest contractor in the market. For teams who want to freelance, we are not a good fit (and most likely more expensive). Where we do shine is an in-house team that does not have the bandwidth to hand-hold each external contractor one by one to become productive. And with that focus, our devs get to enjoy a fixed base stipend, career ladder internally to grow and successfully joining our customers and / or larger corps like Meta, Google and so on
But I also feel there is a little bit of a pandora’s box here.
The model you’re creating here is more structured ‘gig economy’ path for software dev. Sure, you’ve got things like UpWork, and other freelance products, but the purchasers (e.g., business) are effectively taking a risky bet on the work which can tamper commitment to purchasing work that way.
But with ‘no merge, no fee’ could create a very strange dynamic where companies will opportunistically throw work over the wall and create bounty-like dynamics. I don’t know if this is particularly bad for the purchaser, but for the seller that could lead to some challenges overtime (race to the bottom etc)
If it is abused we would take action to intervene but hasn’t happened yet. When it does happen (< 5%), it’s really good learning feedback for devs
But would you reckon there is another way to solve the power imbalance problem?
Worth acknowledging that GitStart has, at least in the past, submitted PRs to open source projects unsolicited in an attempt to bolster their reputation.
We found their PRs to be of extremely rough quality - exactly what you would expect from junior offshore developers - and it took up a non-trivial amount of our time to deal with the contributions and get them into a state where they could be merged. We would also often find 10+ email addresses associated with a single one-line change commit, which I found quite odd.
While I/we encourage contributions from developers of all levels, it felt super iffy that we were investing in coaching the junior developers of the YC/VC-backed startup, only for them to use us for cred.
In the end I believe we blocked GitStart from our repo.
I remember your case personally and reached out to you over email to apologize at that time last year. If there is anything else did wrong, please let us know
It is sad that developers from global south usually have to perform at a much higher level than their peers at the north, just because unfounded prejudices.
I’ve seen great developers from basically everywhere, but the vast majority is garbage (at least at first).
To be charitable: could have been that the commit started off big and complex, getting modified and reviewed by several people over time... before one person finally figured out how to simplify it down to one line — and so then they rebase-squashed it down to just that line, rather than polluting your commit history with all the intervening nonsense.
The reason we have not done that is because we get all devs to commit full time on the platform, and thats a deal breaker for senior devs. Part time doesnt work well for juniors to reasonable grow on the platform, but I can defn see that working for seniors.
Curiously, how you do see your normal day look like if you could something like GitStart on the side as a part time senior?
I would probably not do it for the money (cant imagine it would pay 150USD/h), but mostly to keep exposure to new codebases, ideas, challenges.
I think you should target this offering at people that already do contracting at first, though I think I would miss the opportunity to talk with the team. It is hard to make big changes (expected of senior folks) without design meetings and coordination.
Also, I go through periods where I only want to work 8-16 hours a week, but even most contract work I find is full time.
So really for me this would allow for more liquidity in my contract work.
I came across them on HN about 2 weeks ago [1] and they serve the needs of COSS (commercial open source software) projects but they seem to be bootstrapped unlike GitStart.
1: https://news.ycombinator.com/item?id=36834686
In the last month, we have rejected quite a few tickets that may have been easily tackled by a senior dev. Including technical documentation for infra, K8S, CLI agents to collect runtime traces, fixing flaky E2E tests and so on.
Hola at me if you are interested! (email in bio)
They had their Show HN about 4 months ago: Show HN: Algora – Paid open-source contributions https://news.ycombinator.com/item?id=35412226
As a result, the end team that uses GitStart has full ownership of all code that gets merged.
However you can assign future bug fixes and maintenance work back to GitStart.
There is nothing stopping devs from getting recruited directly, in-fact we want that to happen! Its a major success story for us when devs get hired, ideally back to our customers :)
i would think gitstart as an extension to engineers themselves instead of working in silo
disclaimer: i used to work at gitstart
(Note: I was not asked to post this)
From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon.
A few ideas to solve that problem.
1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well.
2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it.
Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).
And also agree about engineering teams being super nitpicky. We recently rolled out a change to suggest tickets to add linting / formatting tools automatically based on nitpick comments https://gitstart.com/changelog/ticket-suggestions-private-be...
However, I am very curious about the approach of pushing out process with every PR. Would that come as form of a PR description?
Yes. Always the same though (maybe with some variants you write over time). I think the best might be to guide the receiving party so they act exactly like you want.
Example:
"Hello nice to meet you. We are a bunch of junior devs learning to make production code. We'd appreciate if you'd read our PR. However, if at first glance it doesnt look at all like something you'd merge, please simply send us a "nope" and we'll figure out why ourselves with the help of our mentors. Our goal is for you not to spend time on totally off-road PRs.
However if the PR is interesting to you, please proceed like you always do.
You can always reach us via [some form url that's automatically generated for that PR]"
Something like that that someone who can write and think has writen.
Take control at every step to prevent the receiving party to roam freely with the PR so to speak (unless it's decently good), because they might gonna go left and right - and south otherwise. They'll attack you on superficial thing. Make them a smooth funnel so they dont have to talk to nobody to move forward.
That's what came to mind.
P.s. or send them a url they follow entirely.
1. Read the PR in 15 min and come back here
2. How do you like it at first glance? A) very much, it's merged already, B) it's okay but I have feedbacks, C) not at all what we need sorry.
Etc.
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
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.
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.
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
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.
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.
> Neo led the round alongside Microsoft CTO Kevin Scott, Google VP Parisa Tabriz, Andela founder Iyinola Aboyeji, Uber CEO Dara Khosrowshahi, Instagram VP Maria Zhang, Circle CTO Li Fan and VP Yongsheng Wu, Robinhood VP Surabhi Gupta, Quora CEO Adam D’Angelo, GitHub technical advisor Omoju Miller, Gigster founder Debo Olaosebikan, BloomTech founder Austen Allred, Replit CEO Amjad Masad, Airbnb co-founder Nate Blecharczyk, Mike Schroepfer and others.
I wouldn't exactly call this list unremarkable
I can see image on the left, but the form on the right is offscreen and I think you disabled scrolling so there is no way to get to it.
I had to look at this page on the desktop to learn about that form.
For now, it's best to sign up from a desktop, as the onboarding flow requires connecting GitHub and specifying repos, so this is not very convenient from mobile right now.