4 ms·
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 p
by 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 agoBest 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 agoAh 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 agoAnd 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."