3 ms·

Some great advice. Interesting the explicit references to IRC and email, which is (unfortunately? perhaps?) out of date in these days of github issues and Slack

Some great advice. Interesting the explicit references to IRC and email, which is (unfortunately? perhaps?) out of date in these days of github issues and Slack. The original article is 2012 with PRs back to 2016. My current gig is part of a microfrontend/microservices scheme where each team owns the entire vertical from concept and design through full stack, and there are, gee, 40+ services working in concert with more planned. All of these merge into a single web application. It all works shockingly better than might be expected, but it takes a culture of constant vigilance and care along with automated integration including lerna, yalc, renovate, artifactory, et. al. For our team, the branch management scheme is 1 branch per JIRA ticket, then PR with automated checks including tests, lints, code review. The dev decides whether to merge, squash or rebase to master with some input from the lead. That master is just for the microservice, which may or may not need to be merged into another parent service.

prionassembly 5y ago
> each team owns the entire vertical from concept and design through full stack, and there are, gee, 40+ services working in concert with more planned. All of these merge into a single web application. My startup is developing that way, although with more like 9 services owned by 3 developers. (We have no bus factor). Is there anything interesting I can read about your methodologies -- I mean standard references, books, tutorials? (Lerna? Yalc?)
- rendall 5y ago
  It's a really unusual setup, so I'd be surprised if there were a reference book on it. What makes it work is the engineering culture there, and not so much the tech stack recipe. The unusual features are that you're expected to prioritize helping out a fellow engineer if they ask for help, even from another team; and there is a culture of being blunt with criticism. You're expected to be straightforward. I've heard a junior engineer bluntly tell the team that we're wasting time in a meeting, and everyone agreed, apologized and got back on track. This is on top of the standard cultural best practices of no-blame, psychological safety, team autonomy, mandatory work-life balance, etc. The downside is a long onboarding process.

prionassembly 5y ago

> each team owns the entire vertical from concept and design through full stack, and there are, gee, 40+ services working in concert with more planned. All of these merge into a single web application. My startup is developing that way, although with more like 9 services owned by 3 developers. (We have no bus factor). Is there anything interesting I can read about your methodologies -- I mean standard references, books, tutorials? (Lerna? Yalc?)

rendall 5y ago
It's a really unusual setup, so I'd be surprised if there were a reference book on it. What makes it work is the engineering culture there, and not so much the tech stack recipe. The unusual features are that you're expected to prioritize helping out a fellow engineer if they ask for help, even from another team; and there is a culture of being blunt with criticism. You're expected to be straightforward. I've heard a junior engineer bluntly tell the team that we're wasting time in a meeting, and everyone agreed, apologized and got back on track. This is on top of the standard cultural best practices of no-blame, psychological safety, team autonomy, mandatory work-life balance, etc. The downside is a long onboarding process.