andreimackenzie

It can help to establish rules such as "new DB migrations must always be compatible with old code" aka "migrations first". This gets everyone into the mindset that a db+code change must be carefully staged in a way that both (new DB, old code) and not just (new DB, new code) are tested. If the migration goes wrong due to different data in prod, it's easier to roll that back before new code is deployed.

I don't think this is the norm. My experience is at least as anecdotal, but most of my friends in tech seem to work pretty hard.

No dress code is now a perk? Yikes.

The CEO may blame a lone underling, and congress may blame a lone CEO, but congress shares in the overall blame. Regulation and stiffer penalties are needed to balance incentives so that corporations are motivated to invest in security. As things stand, executives seem to rationalize skimping on security as a smart business decision.

Completely agree. One of git's strengths is the flexibility to support many development styles and workflows. It's possible for each developer to follow their own style locally, but still have a consistent team style once commits land on 'master' following rebase.

Learning about interactive rebase greatly aided by local development flow, because it freed me from too much agonizing about commit structure before much code is written. It's a lot easier to decide how to structure commits to tell a story with the code in front of you.