3 ms·

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 re

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 (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).
- robertlagrant 3y ago
  "I know our process diagram for ISO9001 says we do all that fancy stuff, but actually when we release we tell Bob down the corrider who has an Excel macro that pulls all the code from Git, builds and deploys it. It comes out a bit different every time!"
  - hzia 3y ago
    And to keep memory usage under control, we restart the non-deterministic service every 2 days because we were too scrapy to clean up memory after using it. Jim said we will add more bugs fixing it so we believe him.
    - robertlagrant 3y ago
      "We got it approved by calling it Chaos Engineering."

by hzia 3y ago

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).
robertlagrant 3y ago
"I know our process diagram for ISO9001 says we do all that fancy stuff, but actually when we release we tell Bob down the corrider who has an Excel macro that pulls all the code from Git, builds and deploys it. It comes out a bit different every time!"
- hzia 3y ago
  And to keep memory usage under control, we restart the non-deterministic service every 2 days because we were too scrapy to clean up memory after using it. Jim said we will add more bugs fixing it so we believe him.
  - robertlagrant 3y ago
    "We got it approved by calling it Chaos Engineering."