5 ms·

IMO this doesn't help solve backlog problems, it just means paying the (non-headcount) costs of a junior dev while not even making people investment that will m

IMO this doesn't help solve backlog problems, it just means paying the (non-headcount) costs of a junior dev while not even making people investment that will make it worth it later. 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.

hdjjhhvvhga 3y ago
Yeah, that's exactly the reason why junior positions in my niche are almost non-existent. Everybody wants to have seniors or at least regulars, but a junior just means problems for everyone. And you can't be sure they will stay once they learn enough.
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 (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!
- ye-olde-sysrq 3y ago
  I mentioned it as a footnote, but: "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.
  - 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 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.
    - ye-olde-sysrq 3y ago
      Ah good point w.r.t. the frontend focus and having documentation for your internet-facing API (even if it's not "public" per se). So they could probably test it against the prod API without needing to do arcane deploy or dev environment stuff. I was mostly thinking of backend dev. (stereotypical backend dev behavior I suppose).

hdjjhhvvhga 3y ago

Yeah, that's exactly the reason why junior positions in my niche are almost non-existent. Everybody wants to have seniors or at least regulars, but a junior just means problems for everyone. And you can't be sure they will stay once they learn enough.

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 (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!

ye-olde-sysrq 3y ago
I mentioned it as a footnote, but: "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.
- 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 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.
  - ye-olde-sysrq 3y ago
    Ah good point w.r.t. the frontend focus and having documentation for your internet-facing API (even if it's not "public" per se). So they could probably test it against the prod API without needing to do arcane deploy or dev environment stuff. I was mostly thinking of backend dev. (stereotypical backend dev behavior I suppose).