This reminds me of a conversation I had with a Google SWE friend last year about the new gmail interface. I complained that the default settings looked terrible, and that there was barely any space for actual content. He said he disagreed and that everyone he worked with thought it looked great. He eventually realized I was using a 13" macbook air, and said "oh, we all use 27" monitors and macbook retinas". Yeah, not so helpful for me :(

GMail is obnoxiously slow on most of the computers in my house; none of which are more than five years old. Several laptops, a few media players, et al. It's even slow on my new tablet when I use the desktop interface (because the mobile interface lacks necessary features). Chrome and Firefox both soar to max a core and cause the fans to scream for a good half minute while loading the page, then navigation and manipulation is excruciatingly unresponsive.

It's the same for most of Google's web services. They built them for themselves, and neglected to assure that they would work on the majority of the install base of PCs. It reflects poorly on Google's software development process and the quality of its management.

The same thing can be said about Chrome. I was previously on 3gb ram. It ran so fucking slow. Firefox was much better. Now I added on 8gb and chrome runs very fast is more responsive than Firefox. The first thing that came to my mind was that developers have optimized for their own environment rather than what most users have.

For some African developers like me, it's like 2G on some days and 0.1G on other days.

I built a product that embraces offline completely. It permits companies and individuals share files in their LAN over Wi-Fi. File sharing shouldn't be limited to the 'cloud'.

nice! just out of curiosity, what city are you in?

I insist on using the minimum spec device for every product that I work on; it means that my job is often frustrating, but we build better products as a result.

Absolutely.

"Programmers with fast computers write slow code" has been my justification for always buying a cheap shitty laptop, and my excuse for still not having a SSD...

Similarly: "Programmers with reliable Internet connections write unreliable code."

I gave in to the SSD craze because OSX became unusably laggy without one.

Using a Mac is the first thing to stop doing, if you're at all interested in targeting the median case.

Silicon Valley's obsession with high-powered boutique notebooks and the high-frequency replacement cycle of Apple products is in part why so much software that comes from the region is inaccessibly slow.

FWIW, I write software for servers, not clients. But yeah, I understand what you're getting at.

That said, I'm fine with folks using top of the line computers for developing, just not for testing. Nothing will frustrate you more than attempting to use an IDE on a memory and CPU starved system with a spinning rust drive. Nothing prompts you to silly shortcuts more than having a minute plus code/build/test cycle.

But once the coding is done, pull out that netbook from 2012 and make it run fast on that platform.

I've found using the most un-optimized code i can on a lower spec device for the entirity of development really helps with writing faster code.

When I run it through a minifier, optimize a few things, remove the debugging code, and run it on a "recommended" spec device, things run so much faster, and it's nice. It gives a nice feeling of accomplishment in addition to the other benefits.

It also lets us say no to UI features that would run too slowly early on instead of wasting time on trying to get them running on the lower spec hardware.

This. Get an iPhone 5c with slow cellular data plan and make your app fast there. People will love it!

Same reason I give my devs a really slow database server to develop on :)

Developers have never had empathy for end users, in part because they always have had better hardware than the end users did. (Because developers love computers and splurge on the good stuff, where most users don't care and just buy the cheapest they can get away with.)

It's a problem that's been around forever. I dunno how we solve it, but I applaud Facebook for at least trying.

I think the internet really exacerbates the problem though. It's one thing if PowerPoint animations don't work well on an old computer, but with network requests it's like people don't even realize that something that happens quickly on localhost will hit a lot more latency in the real world.

I like this explanation (somewhat down the page) of why Twitter changed in 2012 from a single-page app to more server-side rendering. http://tomdale.net/2015/02/youre-missing-the-point-of-server...

It can also be a problem in business apps where developers don't consider the restrictions on a network.

I have regularly seen apps link to third party social network libraries synchronously. The problem is that corporations will routinely block things like Twitter. You have to wait for the connection to timeout because the domain is blocked.

Also http connections are often closed prematurely by proxies and firewalls and can take seconds to restablish. Apps will often lack sufficiently robust keep-alive so the user will suddenly have an unreposive site.