hzia

7 ms·

31.
by hzia 3y ago
Did you go through the PR discussion though? In this particular case there was technical discovery on a non-trivial approach to patch an npm package (which didn't work out) But above aside, one can get a lot more milage out of GitStart
32.
by hzia 3y ago
No merge no fee was really there to guarantee quality and bootstrap trust. We take the hit and pay the devs either way. If it is abused we would take action to intervene but hasn’t happened yet. When it does happen (< 5%), it’s really go
33.
by hzia 3y ago
Appreciate the feedback and for trying it out! You are spot on that GitStart works really well for teams that have a culture or a strong intention of doing that
34.
by hzia 3y ago
Its our own measure to incorporate PR size, technical complexity, repo complexity and a few other factors Essentially it allows us to give standardise pricing for similar PRs regardless of time spent on them. Would it be more useful if we l
35.
by hzia 3y ago
Love the analysis! Usually the closed number is higher because there are still many edge cases where PRs get closed outside of bad code. E.g bug already fixed in master, follow up PR, PRs merging into a larger one and so on I think basic NL
36.
by hzia 3y ago
It was a day and night difference during and post-pandemic. I used to get on calls to try to explain the value of writing tickets and creating PRs for reasonable sized teams (many orgs were trunk based). That discussion doesnt happen often
37.
by hzia 3y ago
You are totally right about human interface management. For software engineers, that bar is really high as devs by default engage in a ton of tools for their day to day work to convert tickets to PRs And also agree about engineering teams b
38.
by hzia 3y ago
Thank you! Feel free to email me (in bio) to try it out on the open source projects, especially if its related to postgres :)
39.
by hzia 3y ago
> what's stopping you then from hiring junior devs full-time at all? 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
40.
by hzia 3y ago
We have seen that GitStart works best when its meant to accelerate an in-house team, instead of being a member of your team. As a result, the end team that uses GitStart has full ownership of all code that gets merged. However you can assig
41.
by hzia 3y ago
Best comment so far! Everyone has been Jim at-least once before. 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 r
42.
by hzia 3y ago
Any lessons to share other than that?
43.
by hzia 3y ago
We get this request often and personally I would love see this happen! I know quite a few senior devs who want to contribute reviewing PRs or contribute in the tech stacks they love with no strings attached. The reason we have not done that
44.
by hzia 3y ago
I am really sorry you had a bad experience. As a bit of background, we started OSS contributions initially as a way for new devs who were ramping up to grow on open source repos. We learned a lot, and from feedback, we took that away and fo
45.
by hzia 3y ago
> "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? 90% of compensation for devs is base and doe
46.
by hzia 3y ago
It is on our roadmap to properly integrate DCO on the platform, as its a hard blocker for all repos under the linux foundation. We already add each devs that touches the PR internally as co-author now The problem lies in the definition that
47.
by hzia 3y ago
Completely agree on jr devs being net-negative! The cost however is far more than the PR itself (onboarding, fixing their environment, helping understand how react hooks work and so on). With GitStart, we take everything else away entirely
48.
by hzia 3y ago
It's the main topic for majority of my calls with engineering teams using GitStart (Other than convincing them at times to add auto formatting, linting and basic guardrails to your codebase lol) It got a lot better with covid which sta
49.
by hzia 3y ago
We used to for many years at the beginning, and over time started to try a few things to reduce it over time We first got the more experienced junior on the repo review others. Later on, we started to enable multiple devs to work on the sam
50.
by hzia 3y ago
Yes it does feel inverted and rightfully so. Because of that, juniors are net-negative by default which surprises most teams when they hire junior devs for the first time. We are not fully there yet, but you can see from the Open Source PRs
51.
by hzia 3y ago
GitStart is one of those services that are "too good to be true". Getting customers or devs to sign up was easy, so we never really did a launch. The harder part was getting the system to work (aka ship solid PRs while delivering
52.
by hzia 3y ago
I agree with you that one does not have to be excited to ship production quality results. I was previously referring to the 'external "didn't care" enough' which is generally true, and IMO not an inherently bad thin
53.
by hzia 3y ago
You can potentially use CopyBara https://github.com/google/copybara We go much further than CopyBara by syncing CI / CD pipelines, syncing review comments and so on. We are considering launching GitSlice as produc
54.
by hzia 3y ago
thanks for the heads up! We are fixing it right now
55.
by hzia 3y ago
In the early days, we used to pay devs for every PR. That in-fact caused the issue you mentioned where devs would start chasing rewards. Now, devs are paid as a base either way, with light incentives if the PRs are merged with low review cy
56.
by hzia 3y ago
We’ve only automated onboarding for JS/TS, but support more, like most JS/TS frameworks (React, Node, Vue), Django, We have automated on-boarding flow only for JS / TS, but we in-fact support 15 tech stacks including React Na
57.
by hzia 3y ago
> 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? That’s correct. Either you are a full time emp
58.
by hzia 3y ago
I think thats reasonable. Mission aside, this is only going to work if you get solid PRs that are easy to merge. Even with no cost if no merge, there is still a high opportunity cost if your team reviews a PR and doesn't merge it. Whic
59.
by hzia 3y ago
You are right. Most teams in-fact dont hire junior devs for the fear of spending too long to review their PRs and hand-hold devs. We have been able to eliminate a lot of un-usable PRs by having a very strong internal peer review and QA proc
60.
Launch HN: GitStart (YC S19) – Remote junior devs working on production PRs
235 points by hzia 3y ago|192 comments

More ›