3 ms·

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 da

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 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-beta 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?

quadcore 3y ago
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.
- hzia 3y ago
  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 3y ago
    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 3y ago
      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.

by hzia 3y ago

quadcore 3y ago

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.

hzia 3y ago
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 3y ago
  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 3y ago
    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.