greenleafjacob
Keep in mind Imgur is not a large company despite their high traffic, even at their peak of employees the engineering team was pretty small (probably about 12-15 people after series A), and the mobile web team in particular was a handful of people, with a handful of people on iOS and Android, and a handful of people on desktop/backend/API (where I worked).
That said, I think Alan does care about these things. I know at some point they did support NoScript and did care about the experience with JavaScript off (and had code to support uploading images and viewing images with no JavaScript at all). But it's hard to have it as your top priority when Reddit and Instagram are trying to eat your lunch.
I'm sympathetic with the page bloat problem and noscript and I do think more effort should be spent on optimizing this stuff, especially because bandwidth is much of their opex.
[1] Posting, voting, commenting, uploading, accounts, tagging, albums, search. There is even a hidden-ish feature to "auto-browse" in a slideshow-like manner which you can find if you crawl around the source code.
If a company never issued dividends and never bought back their own stock, then there would be no reason for investors to buy stocks in the first place. Most investors don't invest out of the goodness of their hearts, they invest to get a return on capital.
There are certainly changes that cannot be rolled back such that the affected users are magically fixed, which is not what I am suggesting. In the context of mission critical systems, mitigation is usually strongly preferred. For example, the Google SRE book says the following:
> Your first response in a major outage may be to start troubleshooting and try to find a root cause as quickly as possible. Ignore that instinct!
> Instead, your course of action should be to make the system work as well as it can under the circumstances. This may entail emergency options, such as diverting traffic from a broken cluster to others that are still working, dropping traffic wholesale to prevent a cascading failure, or disabling subsystems to lighten the load. Stopping the bleeding should be your first priority; you aren’t helping your users if the system dies while you’re root-causing. [...] The highest priority is to resolve the issue at hand quickly.”
I have seen too many incidents (one in the last 2 days in fact) that were prolonged because people dismissed blindly rolling back changes, merely because they thought the changes were not the root cause.
If you have a good CM system, you should have a timeline of changes that you can correlate against incidents. Most incidents are caused by changes, so you can narrow down most incidents to a handful of changes.
Then the question is, if you have a handful of changes that you could roll back, and rollbacks are risk free, then does it make sense to delay rolling back any particular change until the root cause is understood?
[1] https://www.repository.law.indiana.edu/cgi/viewcontent.cgi?r...
https://www.theregister.co.uk/2015/01/06/dev_blunder_shows_g...
[1] http://www.kalenyuk.com.ua/wp-content/uploads/2009/12/varnis...
Other than mining fees?
Employees are typically prohibited from shorting the stock.