andreimackenzie

I am getting an `alert(1)` when visiting this site. This smells like cross-site scripting. Beware.

I'm happy to read encouragement to consider the wider group of stakeholders in the scope of testing. In many organizations, incentives are out of alignment to find issues beyond the obvious user-facing correctness ones, so "testing theater" wins, because it allows teams to declare victory more quickly. Software as a discipline would benefit from more testing attention to security, accessibility, usability, etc.

Arriving at Penn Station has benefits if you're traveling for business. Hailing a ride to get to an office within 15 minutes beats the long ride to get downtown from one of the NYC airports.

Agreed. Jira makes it easy to add a new field, plugin, or workflow step for a particular use case, but it is much more difficult to determine if an existing field/plugin/workflow step can be safely removed. As a result, everyone is afraid to touch it, projects accumulate cruft over the years, and it degrades the entire workflow. The problem is especially bad if there is shared ownership of JIRA, and therefore everyone feels empowered to add, but nobody feels responsible for the dirty work to clean up the mess from time to time.

My company had resisted the urge to bolt on additions more than most. We recently migrated from Cloud to on-prem Server as a result of being acquired, and it is amazing how much zippier our project is compared to some of the peer projects that have accumulated cruft.

I completely agree that some types of changes are much more expensive with a bare metal architecture than with cloud.

6 years ago, I worked for a company in the mobile space. This was around the time of the Candy Crush boom, and our traffic and processing/storage needs doubled roughly every six months. Our primary data center was rented space co-located near our urban office. For a while, our sysadmins could simply drive over and rack more servers. We reached a point where our cages were full, and the data center was not willing rent us adjacent space. We were now looking at a very large project to stand up additional capacity elsewhere to augment what we had (with pretty serious implications on the architecture of the whole system beyond the hardware) or move the whole operation to a larger space.

This problem ended up hamstringing the business for many months, as many of our decisions were affected by concern about hitting the scale ceiling. We also devoted significant engineering/sysadmin resources to dealing with this problem instead of building new features to grow the business. If the company had chosen a cloud provider or even VPS, it would have been less critical to try to guess how much capacity we'd need a few years down the road to avoid the physical ceiling we dealt with.

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.