PR's are not split into submodules/frameworks for distinct review purposes. Functionally though, right now we have three distinct monorepos (not very 'mono' but we're working on it!), that represent our three main development stacks.
In our PR tooling, there's nothing that enforces/encourages scoping changes to a specific subset of any given repo. We generally encourage smaller PRs as a best practice, but a huge chunk of the benefit of a moonorepo is folks can make cross-cutting changes if/when necessary.
We have some custom goo on top of Github that manages the review flow. Specifically, we try to make it easy for folks to farm out reviews to the teams that own the code you're editing, so they don't have to hop in Slack and track down reviewers.
yeaaah, I used to hold this view and drove a team - hard - to essentially pull apart a monorepo into different components with clear contract boundaries. It was by far one of my greatest errors in professional judgement.
at the risk of coming up with a contrived example: let's say you own a service that need to deserialize a datetime in a request in a format you don't currently support. assuming you own the stack, you need to a) update your date library b) update your webserver stack c) possibly update an intermediate webserver stack that includes primitives like logging, telemetry, tracing, auth, service discovery and d) your actual service.
If a->d are all independent, separate components, you have to orchestrate those changes through 4 separate repositories. And god forbid something you did at the lowest point in the stack is completely unworkable higher up.
There's all sorts of rocket science you could do to orchestrate these changes, but it ends up being contrived and edgecasey.
Most of the pain from monorepos can also be addressed with a dash of rocketscience (see:bazel), but the end model tends to have
a) have an easier mental model for the user
b) allow for consolidation of infrastructure work. Ie, your build/ci/language tooling teams can focus their efforts on one place
c) can coordinate changes across the entire stack within one field of view
d) can coral some of the worst, disparate instincts of a growing engineering org (ie, tons of teams optimizing for local maximas without internalizing knock-on effects).
Its important to avoid deep dependency chains when doing this, yes. I usually recommend a "framework" multi-package repo and then multiple "application" / "service" repos.
I like having examples, even contrived ones, but I'm not sure I understood this one. Can you elaborate on what you mean? Is it about adding support for a new serialization format for dates in requests to a service? Why would this affect the webserver stack and logging/telemetry/tracing/auth primitives?
I find that a lot of organizations have really strange thoughts on how to factor things into separate microservices and libraries. Usually I approach by asking the following question: if this was an open source-library or service (e.g. like elasticsearch), would you use it? If not, then its probably not a great candidate for a separate thing - lets try and come up with something else.
One way to handle CI/CD is using standardized pipelines e.g. you tag your repo with a tag `app:node` or `lib:js` and the github org pipeline scanner will find it and assign the standard `app:node` or `lib:js` pipeline to it.
A way that I like better but most tools unfortunatley don't support it yet is for the infra teams to publish libraries that are essentially functions taking some parameters and generating (standard) pipelines/configuration. Those can then be tracked together the same as other dependencies.
the amount of internal denial about the pay gap between us and FANG companies is pretty silly. a lot of high performers get the principal-band bump tangled in front of them for years as an incentive. (level 66+. level 65 is the first "principal" level but doesn't get the non-linear comp boost yet).
Oh lord, product studio. Back in 2013 the preferred method of filing workitems for a given "wave" was to load this spreadsheet, do weiiird formatting, and indentation, type up all the workitems you foresee for the next sprint and then press a magic "send to product studio" button." God help you if you messed up some of the nesting or wanted to reorder anything - honestly I would just wipe it clean and start from scratch.
Ironically my team just finished a product called RAID that was designed to kill bugs in product studio and move them to DevOps. There are still pockets of teams that use Product Studio within Microsoft - the sufficiency gap is real - but they're the overwhelming minority now.
I had absolutely zero problems with product studio when I used it from 2008-2011. It was a very 1990s style MDI application, somewhat representing the peak of win32 ux design, short and to the point, and as long as the servers were happy it "just worked".
I'm a big 'ol fan of Stripe, but large scale change isn't going to happen through corporate self regulation.
I wish tech companies that insist they want to make large, positive changes would come to terms with the fact that putting pressure on political levers is fundamentally necessary. I would be far more aggressive in my support of this effort if it was explicitly "we're doing this effort to cover our own tracks and we're contributing to a PAC that will support politicians who prioritize sensible environmental policy."
I disagree. While there is no guarantee large scale change will be fully driven by corporate self regulation, I'd argue that corporate self regulation, and initiatives like this, have the potential to be substantially more impactful than waiting on help from dysfunctional big government.
yes we need political levers to move, but I'm not holding my breath, and I welcome any and all corporate efforts.
>I wish tech companies that… want… large, positive changes would [accept] that putting pressure on political levers is fundamentally necessary.
I agree that corporate self-regulation is the laziest political solution. But instead of doubling down on a mistake, let's get all company hands off the political levers and have real separation of corp and state. Company influence on politics is an arms race that entrenches the most powerful firms, many of which are fundamentally opposed to climate change regulation.
Absolutely, agreed. But unilateral disarmament isn't the way to do so. If Stripe has a nice post about vehemently supporting politicians and policies that aim to get corporate money out of politics, they will quietly get my upvote and thoughtful nod of approval.
You can't throw a wifi-enabled juicer 5 feet without hitting half a dozen companies that are trying to be 'technological catalysts'. You're giving extra credit for unproven rate of return, which I'd still argue won't amount to meaningful change unless the political status quo is aggressively challenged.
The reason you spent $Xmil on a PAC is the same reason we (inclusive, hopefully) vote. Will one significantly contributor turn the tide? Probably not. But it requires good (corporate) citizens to put up or shutup instead of leveraging a tweak on a pet environmental project to gain a positive press cycle.
The big difference I see is that that the Google Photos share model feels related more to mobile-sharing scenarios than access control - ie, you're sending your buddy a link! Vs you're granting access, and that distinction isn't super blatantly called out.
I always tell people that my life-saving workout device was the Kindle 3. In 2010, I was 315 lbs, sedentary as hell and not making any progress to fix that. The idea of running just seemed like complete drudgery.
I ended up making a pact with a friend to meet up at the gym every morning, and I took my kindle and reread a long epic fantasy series page by page. I started off stupid-slow, with a slight incline. First 25 lbs shed without a problem, and steadily increased my pace.
I've now graduated to actually running outside (yay!) and distracting myself with podcasts, have completed 2 half-marathons, and at one point was down to ~210lbs.
People's motivations and activation hurdles are different - for me it was boredom and accountability - which I fixed with a book and some peer pressure.
That's awesome to hear. Often on HN I see people being negative about things like running or meditation for example, adamently saying these things didn't work for them and won't work for everyone. I don't see the point in coming up with a solution for everyone. We all know people don't work that way. Personal anecdotes are a great way to get inspired based on actual experiences. Even if it is shown that some activity doesn't work for everyone, if it works for one person, it's worth sharing!
But depending on how stringent your bounding box for "culture fit" is, you end up building an archetype for age, gender, education and ethnicity of your target employee.
The point is is that if you're targeting people who behave like you, have plenty of shared interests and reflect your own way of doing things, those people are going to end up looking a lot like you too.
I think the point that potatolicious is trying to make is that the ambiguity of "cultural fit" ends up becoming a path to hiring people who are very similar to yourself. An alternative approach would be to define explicit, concrete values that your company and team reflect, and look for hires that mirror those values instead of nebulous "cultural" fit.
