I also wonder what that graph looks like. DC was a tech powerhouse for a while with dulles corridor and the likes of AOL et al. But I'm not exactly sure when that really dwindled. I could see something resembling a U shape from that going down but DC growing if you changed the starting date a little later. Just throwing it out there, and Amazon will probably increase those numbers. The city's tech growth may not be stunning but the city itself is growing and there's definitely no shortage of money.
I had problems visualising things, when reading it in English. Many years ago, when I started working on enterprise applications, I would come across terms like "Provider" which I would read about and then forget. I guess I could not make simple connection between the technical term "Provider" and the real word abstract noun. This made understanding simple design patterns or abstractions harder. A lot of times when you know the literal meaning of a technical word and can visualize it in your head, understanding the related concept becomes a lot easier.
No in the sense that we have several thousands repos. Yes in the sense that some of these repos frequently contain several packages, both apps and libraries, when they're closely related and owned by the same group.
The goal though is for repos to map to team ownership (a team should be able to own its stuff, as I mentioned above), and teams are a very malleable thing (they merge and split all the time). Having repos be very small helps a lot with that (and helps tools scale without needing to do anything special)
Do you find that managing versions between the different repos causes overhead? Besides allowing independent main branch management, what are the advantages of having many small repos instead of one that contains all of your apps?
Version management is a fallacy as far as benefits of mono vs poly repos. You can do one way or another either way. You can have 1 version of everything in poly repos or you can have mixed versions in monorepos.
We follow an eventually consistent model. That is, we strive to have 1 version of dependencies for everything, but allow temporary deviation. Sometimes those deviations are less temporary, but usually for reasons that would have prevented upgrades altogether for everyone if we enforced a single version for everything.
The main benefits are around ownership (people can do whatever the hell they want to their repos) and tooling/scaling (whatever works for your tiny personal project will work for any of our apps without needing to scale them). Those are separate benefits from monolith app to micro apps (because again, you can do either with either model). You also have some minor benefits that would be easy to work around but are nice to get for free (eg: Github's default history is actually useful in the web UI)
The only tooling you need to manage poly repos is something to do pull requests at scale when something needs to happen everywhere. You can everything else (eg: build management scoped to individual projects) basically for free, you can always clone the entire repo without issues, etc etc etc.
What you are asking for is the ideal culture. I now work with a team which share these values and working here has been very fulfilling but it was not always like that for me. I have worked with teams with worse cultures and never really understood the importance of these soft skills, but once I got a chance to work with a good team, I acquired these soft skills.
Good point, my first job was at a place that didn't have a great culture either. It wasn't until my second job that I started developing my own soft skills.
