This works well for a couple dozen repos per team in my experience. It’s also my preferred way to work.
It doesn’t scale so well to hundreds of repos per team without significant tooling. At some point anything cross-cutting (build tool updates, library updates, etc) becomes hard to track. Repos are left behind as folks change teams and teams are reorg’d.
I’ve never worked in a monorepo, but I can see the appeal for large, atomic changes especially.
Breaking down work so it can be delivered incrementally is an underrated skill.
Simplifies communication about progress, builds confidence in ability to deliver, and makes it easier to avoid getting lost in rabbit holes. Especially in situations where there are lots of unknowns - unknown programming language, multiple tools to choose from, etc.
My work isn't what I would call highly professional in terms of infra, but for us the old URL from our Jira move is dead and gone (including the parent domain) but the ticket references work in the new instance (redirecting to a new project name also). I think you just have to pick your poison, nothing's going to work all the time without small amounts of effort from IT.
Definitely - we recently moved issue tracking to another system after 15+ years and found there were too many links to abandon, so we run a service that just redirects old URLs.
This 2006 Stanford interview[1] with Kelleher sounds like taking ideas seriously was an important part of the culture. Tragic it was lost, as it always stuck out in my mind as an example of great leadership.
> Southwest continues to encourage and applaud out-of-the-box thinking from everyone at the company, from flight attendants to top-level executives. He recalled one mechanic, for example, who submitted a sketch showing how to fit an extra seat onto the aircraft, in order to compensate for some over-wing exit seats lost due to a new federal air safety regulation.
> In general, Kelleher said, if a Southwest employee submits an idea like that, he or she can expect to get an answer back within a week, and a lengthy explanation to boot. The point, he said, is “never spoil an idea, because when you spoil an idea, you ensure that you’ll never get another one from that person.”
> Does this new language save you that much over using a more generic and widly known language in the org?
This is a great question to ask. It’s worth extending beyond language to frameworks and libraries as well.
It’s important to optimize for the development experience across all the apps in a team. Especially once the excitement of using a new language is gone and there are bugs to fix.
I‘ve rewritten a few projects in a common language for the org. Each time the biggest benefit was how straightforward it became to work on. Problems you’ve found somewhere else become easy to spot (and search for). Writing another test is the same as the last project you had open. Anyone in the org can contribute with a minimal learning curve. This can be the difference in getting bugs fixed in a day or a month.
I've been a subscriber to NHL Gamecenter for two years. If you're very far from your home team, it can be a good deal.
In California, I can catch most of Detroit's games. In a major hockey market like Toronto, however, Detroit's games are often on TSN2 (think ESPN2), which means they are blacked out. Cable was the only way to see these, even though I would have guessed they were out of market.
It does sound like they were debating this for quite a while. Eric Lippert used to work on the C# compiler and published a blog post[1] immediately after the announcement:
Since I always knew that open sourcing was a possibility I tried to write my portions of it as cleanly and clearly as possible; hopefully I succeeded.
This works well for a couple dozen repos per team in my experience. It’s also my preferred way to work.
It doesn’t scale so well to hundreds of repos per team without significant tooling. At some point anything cross-cutting (build tool updates, library updates, etc) becomes hard to track. Repos are left behind as folks change teams and teams are reorg’d.
I’ve never worked in a monorepo, but I can see the appeal for large, atomic changes especially.