sghill

Up to what scale?

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.

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.

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.

The old URLs aren’t kept around to redirect to the new location?

I’d like to see better centralized support generally from CI systems. Six months of steady migration and a custom DSL seems alarmingly common.

CI Wishlist:

* testable outside of CI

* required steps based on repo characteristics (ex: security scans)

* central step and workflow definitions

* controlled rollouts/rollbacks to simplify migrations

> 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.