chase-seibert

This decision makes sense from the perspective of the person who owns doing database migrations, or who owns the performance of the database.

However, the other 99% of the engineers in the company end up dealing with the fallout of not having FKs -- more bugs, and slower development velocity.

One alternative is to have FKs in smaller, sharded databases, where you don't have to migrate between shards. For example, all the database rows related to one repo could be co-located in a shared with strong FKs between them.

I've done both roles, but my sense is that manager of managers is essentially a more risky role -- chances of being laid off are higher, with accompanying risk. Line managers virtually never get laid off.

Compensation seems similar, as well.

I’ve build a similar tool for a hackathon. What we found when we rolled this out to the whole company was that as soon as they saw the data for other people, they stopped worrying that we had a culture of too many meetings.

ES6 admittedly borrowed a lot from Python. I just wish Guido had been successful getting Python supported as a first class language in Chrome; that might have actually given us a choice in the browser. Even then, I find it hard to imagine that ALL other browsers would have followed suit.

Certainly a number of common interactions are not currently possible (or at least not optimal) without being able to use JS. Maybe some day we can get to a place with web components where many of those common patterns can be implemented with plain old HTML again.

+1 I think that React.js is actually a much better model, closer to how you would render full page renders on the server.

I agree. I value what javascript enables for those experience as well. I just wish more sites could implement those useful pieces and still get all the basic interactions correct. Too often, those are broken, I assume due to ignorance.