The tools being used to create a piece of software are often fundamentally different than those used on the other end.

This means that machines should be provisioned in accordance with the needs of the actual tools running on them.

Developers may in addition to running different tools may need to iterate quickly in order to test functionality. It may be acceptable that an app that is started once at the beginning of the day takes 3 seconds to start but if you deliberately handicap developers machines and it takes 7 each time the developer is trying to fix a bug in the space of a few minutes instead of 1 on a faster machine you may have damaged your own productivity for no reason.

This has no nothing to do with the idea of who works for whom. Incidentally this statement sounds entirely passive aggressive. Ultimately I'm pretty sure all of you worked for whomever is your ultimate customer and are invested in helping each other do effective work it sounds like the management team was entirely unclear on how to do this. Is that shop even in business.

Contrary to some of the criticism I'm seeing here, it wasn't actually hated by the development team, either. The hypothetical "can't get any work done because compiling takes a bazillionty days" scenarios that people are pulling out of thin air here simply didn't happen. At a shop where developers were expected to think carefully about performance and know how to achieve it, they tended to do exactly that.

Someone who was busy making excuses about how they weren't very productive because they only got a 3.4 GHz CPU while the analysts got a 3.6 GHz CPU probably wouldn't have lasted long there.

As long as you have time to actually achieve this, remove that and even on the worst hardware, you'll see shitty implementation.

Dogfooding is sometimes a good idea, and of course testing on a range of setups is important. I suspect there is a problem with people testing on older software but not trying any older hardware (especially for web apps), which using old machines could have partially avoided.

But the idea that development should inherently be able to happen on older hardware than the product will run on is arbitrary and ridiculous. At best, that creates pointless pressure to rely on hardware-friendly tools, which could mean anything from not leaving open lots of relevant Chrome tabs to pushing developers to use vim instead of a Jetbrains IDE. (Nothing wrong with vim, obviously, but "we intentionally hobbled our hardware" is a weird reason to choose an environment.)

At worst, it fundamentally impedes development work. For an extreme case: Xcode isn't really optional for iOs development, and merely opening it seriously taxes brand new Macbooks - applying this theory to iOs developers might leave them basically unable to work. Even outside that special case, there are still plenty of computer-intensive development tasks that are way outside user experience. Just from personal experience: emulating a mobile phone, running a local test server for code that will eventually land on AWS, running a fuzzer or even a static analysis tool.

Even if we grant the merit of that trite "remember who you work for" line, sticking to old hardware doesn't seem to follow at all. We wouldn't go around telling graphic designers that if they work for a customer with an old iMac G3, they're not allowed to have a computer that can run Photoshop. Heck, are there any professions where we assume that building a thing should be done exclusively via the same tools the customer will employ once it's finished?

As a senior dev., I still use an iPhone SE, but the mobile dev team all have the latest iPhones.

The app looks horrible on the SE, and some touch areas are blocked by overlapping text or images.

It is basically unusable on a supported device.

Endless performance problems were masked in development, and then very noisily evident when it reached customers. Performance testing was largely reactive and far removed from the creators of some terrible code choices, so they'd tend to shrug ("Works fine here") until you analyzed the hell out of it.

Now, the code was a big C++ environment, and compilation speed was a problem, but maybe a means of testing in a throttled state would have prevented a lot of grief much, much earlier.

This is a really nice way of working and you can see the results when browsing https://mbasic.facebook.com: even at 2G speeds, even with photos, pages load fast. No unnecessary background process trying to do something, all buttons are there to be clicked on already. A really smooth experience.

Developer tools are only resource hungry today because their developers aren't dogfooding.

Developer productivity hasn't improved since, even gone backwards in some ways.

We had to buy cutting edge pc's spend >£2k on extra ram and £4k on 20 inch crt monitors to develop - the application would run on a 133MZ

If you had less than 2 Blue screens per hour that was a good hour - This was early 90's btw.

Where I worked in the early 1990s (1992-ish), us developers fought over who would have the color terminals (Wyse 370/380) and who would have the monochrome ones (Wyse 50/60). I was low-man on the pole so I always got stuck with the low-spec terminal (though I still have an affinity today to amber VT220 text characters).

Until I "wowed" the owner of the company (small shop) showing how to do windows, dialogs, etc in a terminal using a virtual buffer and some other "tricks". Then I was given one of the color terminals, to jazz our interface (which was mostly numbered menus and basic flat screens).

At one point, I played around with the 16 color Textronix graphics mode you could pop into with the right escape sequence; I think I made a very slow Mandelbrot set generator (never showed that to him; our app was already pushing our dev hardware, which was an IBM RS/6000 desktop workstation running AIX we all shared via 9600 bps serial connections)...

The system was SIROS the system that helped manage the UK's SMDS network so we had budget for it.

The 20 inch monitors where awesome for playing doom late at night

Mind you I don't necessarily agree with all of this. Well except the IDE part, Vim and Emacs are tools that more people need to learn.

In every case I've had a dev db running on a shared test server, that DB has been woefully underspecced for the purpose and often in a datacenter with 300ms latency from the office over the company VPN.

While production instances are in the same datacenter as the production DB with 5ms latency.

They should have bought everyone a second low spec machine to test on, and let them use proper dev machines for building the software.

I guess if is a shop where the management feels they need to remind developers suffering through that for 8+ hours a day "who works for who", that was probably the least terrible part of working there.

"Yep, we put those developers in their place."

"Hey, why are they leaving???"

"Oh, you mean we need developers more than they need us?"

You need your doctor more than your doctor needs you. That doesn't change the fact that your doctor is doing work for you, and not the other way around. Same for lawyers, plumbers, electricians, architects, and anyone else working in any number of other skilled professions.