1_800_UNICORN

It's only too bad that SendGrid has struggled to get its marketing email solution off the ground in a meaningful way. If anyone was going to eat MailChimp's lunch, SendGrid would be my choice as top contender. And yet despite SendGrid releasing many iterations of their marketing email solution over the past 5 years they've never seemed to get a lot of success outside of their bread-and-butter transactional email vertical. Their marketing solution brings in less than 20% of total revenue last I heard.

I know that TurboTax is a controversial choice because they are incentivized to fight to keep tax law complicated, but if we ignore the political context, their software works beautifully well. It never does anything I don't expect, when I need more time on a section it's easy to drop out and revisit later, and I always feel confident at the end that I've filled out my taxes correctly.

If I found a political candidate who advocated for mandatory vacation of 4 weeks or more per year, and/or less work-hours per week, I'd give them my vote in a heartbeat. A change of that magnitude for the average worker would reap incredible social benefits for all of us.

As soon as you have enough users that an outage poses a significant risk to your business, you need to invest in either refactoring to reduce tech debt, or a rewrite. And you NEED to add tests, and a robust deployment process that tests changes at multiple stages with monitoring on the basics (server speed and memory usage, database error rate, etc).

OKCupid got lucky in this case.

My advice to them, and my philosophy on this topic, is that technical debt is just that- debt. It's not a dirty four-letter word to be avoided, it's something to be managed the way you manage actual financial debt. There are some projects where the software you build will be self-contained (no dependencies), will require minimal changes in the future, or it may have a short shelf life (e.g. it's a stopgap before you cut over to a new system). In these scenarios, accruing technical debt isn't the worst thing in the world if it allows you to reap business value faster.

When you're building software that's going to live long-term, or that drives core parts of your business (and therefore will need to change frequently as your business changes), technical debt needs to be tackled early and often. It's ok to accrue technical debt in the short term ONLY if you make that decision consciously knowing that you'll need to address it later (e.g. I had a client that needed to release their software for a trade show, so we accrued tech debt and created tasks to track every piece of debt we'd want to tackle later, and then prioritized that work immediately after the trade show).

That said, it's also important to be clear about what constitutes tech debt vs what is over-optimization. Outside of libraries and frameworks, I don't really need the software to be "perfect". I need it to be clear enough, tested thoroughly enough, and easy enough to change to maintain a high velocity. If a part of the code has become spaghetti-like, or if we see code duplicated more than 3 times, or if we have disparate code that's too closely coupled to easily make changes, that's technical debt worth tackling.

The vast majority of organizations I've worked with typically think much shorter term, which is why they find themselves repeatedly accruing technical debt to the point where changes to the system occur at a snail's pace. It takes a lot of discipline, and coordination between IT and business, to practice what I'm describing, but that's the ideal that I strive for and advise my clients to strive for.

The reason I mention this anecdote is not to dispute any of the studies... I understand the difference between anecdotal evidence and quantitative evidence. Just a counter-point to the inevitable echo chamber of complaints about open floor plans being inhumane, a money-grab, etc etc.

"Errors discovered through Instabug are most likely to be resolved within 24 hours of being reported" is one of the TL;DR points, but only ~1.5% of bugs are resolved within 24 hours.

Long answer: nooooooooo.

End of story. Goodbye.

On the other hand, I believe that in 100 years we'll look at today as the dark ages in terms of the scale of our industrial meat production.

So, I'm cautiously curious to see if other companies follow suit or not.

I don't believe that any of those terms apply to people who are fighting against working 72 hours per week for low pay. This is a case of basic human rights. The words that come to mind to describe the folks who are fighting this fight are "proud", "resilient", and "hard-working".

I'm not sure that the original advice given was ideal. I'd recommend consulting with a lawyer first before giving any information to HR given that OPs job was at risk. But I'm happy for OP that it all worked out in the end.

But I REALLY hope they succeed, because I've been a customer since they first announced US support.

I would nitpick slightly. Google core DNA is advertising. Search is a huge component to driving their advertising business, but let's not pretend that they are driven by anything other than ad revenue.

Let's assume a very conservative estimate of 800 students doing 1 of online work, and 200 students paying $12k for a class. That works out to $1.2M in online tuition, and $2.4M in in-person tuition. Given how conservative my estimate is, $375k seems like a pittance for operating without a license and lying about success rates.