Exactly. They can not break out the "my codes compiling" argument. Lost morale over a 2 year old laptop?? Wow, they should work in education. Try a 10 year old laptop and no hope of every buying a new "high end" machine. Try a shiny new $500 dell. I think some new programmers are out of touch a bit on hardware...

> Wow, they should work in education. Try a 10 year old laptop and no hope of every buying a new "high end" machine.

That it is worse in another field is not a very good argument?

Yes because developers who are whining about having to use a two year old laptop because their company is trying to save money seems more like a bunch of entitled brats.

In the end, what matters is that you keep your employees happy. Whether or not they are entitle brats (they are...) is irrelevant if you need those employees.

If you're bringing in 3x your cost (as you should as an employee), the cost of a laptop is very nil for the company. Their nickel and diming you is worse for morale and retention.

Anyone who will quit a job for something so minute as having a two year old laptop is someone that is probably so immature that they couldn’t handle the normal rigors that come from being a professional.

You may think so. When you see certain coworkers get new machines every 2 years but you don't, for example, it builds a power structure when one wasn't before. If you feel less valued as a result, I don't think it means you can't handle the "normal rigors" of being a professional. It means, if you can find somewhere else where you feel more valued, then more power to you.

Again if you can’t handle the “power structure” of not getting a laptop every two years, you will never be able to handle navigating life in corporate America.

If you're bringing in 3x your cost, you're getting ripped off and need to start raking those numbers back in.

Unlikely with a smart employer. Your cost to them is 2x your tc. They need a profit, that's where the last x comes from.

What would you say is a good ratio then?

>seems more like a bunch of entitled brats.

I'd say anyone that drops the money on a 4 year CS education of any rigor, survives it, survives and succeeds at the fairly rigorous interview cycles required to get a job in SWE these days... is absolutely entitled to requesting top of the line hardware to perform their duties.

I'd say your argument makes it "seem" like it's coming from envious, curmudgeonly luddites.

If individuals of other vocations feel that these developers are "entitled brats", perhaps they should switch careers? I can't imagine a teacher went in to education seriously expecting to get provisioned the latest rMBP as a perk?

Are we assuming all jobs are equally dependent on high-end hardware to provide the best RoI for time spent?

Because you think CS is the hardest, most rigorous major?

Where did I say or even imply that?

I simply said it was hard and rigorous. Not the most.

Why do you assume all employed SWEs have 4 year CS degrees? Or any degree at all?

That's fair. Then they've managed to educate themselves, not exactly a non-trivial feat either.

Teaching yourself to program is not rocket science either. I was writing 65C02 and x86 assembly on 6th grade in the 80s. I got a C.S. degree because that’s what I was suppose to do.

It's not "another field", it's literally almost every field other than computing, as outside tech people either don't have money for top hardware, or don't have interest in buying it.

In so far as it makes developer more empathetic towards users, it's a good point to make.

If you were paid at your job the same as in tech, and you know the direct value you add then you'll understand the cost of the tools you prefer is a literal drop in the bucket and not worth serious discussion.

Wow seeing that I’ve been “in tech” developing professionally for over 20 years and a hobbyist programmer in assembly since 12, I think I’ve earned my geek cred...

It's actually you that is out of touch. I could reiterate the arguments already well expressed but perhaps I should just suggest you read the entire rest of the thread.

A teacher spends presumably most hours actually interacting with students and use the computer for preparation and paperwork something your 10 year old dell is probably well suited for during the minority of the time they spend on it.

Your dev spends most of their time on their machine and even if they don't have to build software in a compiled language may still be running a heavy development environment, several browsers to test the result, virtual machines, etc etc etc.

To drive the point home lets consider the cost of a 5% decrease in productivity due to using an inferior machine.

If a teacher is contracted to work 185 days or 37 work weeks in a year and earns 60k the teacher earns $32 at 50 hours.

If the teacher spends 10 hours per week on the computer the cost is no more than $32 * 37 * 10 * 0.05 = $592

If your software developer is earning 100k x 50 weeks and spends 50 hours per week almost all of which is spent using the computer then the cost is $40 per hour x 40 hours on the computer x 50 weeks x 0.05 = $4000

This doesn't account for actual costs incurred by having to hire more developers because management is too incompetent to retain them buy buying them nice tools.

Classrooms often use interactive whiteboards driven by PCs that can be quite slow to log in to the teacher's active directory profile as this involves pulling data over a network of variable speed. There can also be issues with software upgrades deciding to start at random times. The PC will need to be logged off and logged on 8 times a day...

Teachers don't talk to themselves in classrooms so time loss can affect a small percentage of up to 180 student-hours per day or 900 student-hours per teaching week per teacher. A typical '8 form entry' secondary school in UK will have around 100 teachers plus admin / head of subject / 'leadership'. School year is around 38 weeks.

I sometimes think something like ChromeOS but that can run IW software and just stay booted would be better. An appliance.

You need to factor in the time it would take for teachers to move all of their resources over to another format. Some teachers have decades worth of work that they teach with.

The argument you are constructing is that we should invest more money in classroom computers not less in developers.

Yup! Or at least 'appliance' style end points

Editor will be snappier, Docker will start faster, git merges will be quick, etc

it all adds up.

Vim is pretty snappy regardless of hardware!

I do not and have never used Vim, if I started at your company would you prefer to have me waste three or four days learning it or just pay an extra six hundred dollars on hardware?

Just for your knowledge, your answer probably differs from the one I'd get from whoever does the accounting at your company, and their answer is the right one.

> waste three or four days learning it

If you're a proficient IDE user, learning and setting up Vim up to a comparable level to a top-notch IDE (Visual Studio, IntelliJ) would take more than three or four days. Three or four weeks (or even months sounds) more realistic, in order to get efficient:

* code navigation * code refactoring * debugging * tool integration * workspace/project management

Don't let anyone tell you otherwise, I'm a Vim user and the people that say it will take just days or a few weeks have just forgotten how long it took them to ramp up. Or they're fooling themselves that their Vim does everything a capable IDE does on strong hardware.

I agree, but I wanted to clearly under estimate because three or four days is already enough cost wise and it's hard to argue. I think two weeks is on the optimistic side, but I think real proficiency would be a slow process and likely end up not paying off for about a quarter, though you'd be productive in other ways during that time.

At a previous company, I never told the new college grads that there were options other than vi, so unless they were enterprising enough to figure things alternatives by themselves (this was before widespread availability of Linux and the web), they were forced to learn it.

And then I'd tell them about alternatives after they were proficient with vi. Not one ever switched away from vi.

Did that cost us in initial productivity? Probably. But it's such a minor thing when it comes to NCGs.

Good thing I'm not in charge of these things at my company, I'd probably look for people who used hardware properly rather than just rely on Apple to make their POS GUI IDEs to run... Most of my colleagues run IDEs, but not the ones who actually get stuff done.

> three or four days learning it

Now this is being ambitious :)

> I do not and have never used Vim I do wonder, what editor do you use when you're sshed into a remote machine?

I generally use nano for quick and dirty things, but prefer to push/pull changes. The environment I'm working in doesn't necessitate editing local files on a remote very often.

For me, my ~4 year old MacBook Air (Yeah, not really a top end dev machine) has started to struggle with more than 15 or 20 browser tabs open. I regularly spend _way_ more time researching than compiling, so it's starting to annoy me enough to think about pushing for an upgrade.

(I put the blame half on the browser vendors, and half on modern cloud web apps. My tabs usually include Gmail, Jira, Confluence, Trello, and Slack. Even doing nothing, between them they'll sometime have the fans spinning...)

Bundling + dev servers are place a heavy load. I'm actually looking into a way I can avoid using bundling for production but still get some kind of "hot javascript file reload" in the browser.

Getting fast feedback from your tests.

As a counterpoint, tests are your application, and thus should run at the exact specs of your average consumer. And you don't get to compensate for the test suite itself either unless your 100% sure the average customer is only going to be running your app.

This is also a good argument for running tests on a separate dedicated machine

I like running tests on a separate dedicated machine and enjoy a build environment that verifies each commit with a full test suite... but being able to run unit tests for a file on each save of a file is something that can save you some time pretty trivially.

I also disagree strongly about needing to run tests on the exact specs of your average consumer, most of us aren't writing software for a small set of hardware configurations so determining those average specs is likely not possible - but if you're working in an embedded platform or with specialized hardware I do agree that you absolutely do need to run tests on the actual hardware regularly, I'd still argue that those tests should be run on a dedicated machine and should be in addition to tests that verify the code is obeying its contract.

> should run at the exact specs of your average consumer.

Kinda expensive, having a set of multiple dedicated servers (or VMs) running on God knows how many dozen cores and hundreds of gb of ram just to run the tests that my laptop runs fine by itself, all in the name of running the "exact specs" that my stuff is going to be run on.

You're describing system testing, which takes place extremely late in the product cycle.

This argument is particularly badly formed. Tests are your application but you are testing for correctness not speed. In theory your tests could exercise as quickly as possible as many unique operations as a customer could perform in hours of normal use. You would never want this to take hours.

That pesky windows 10 won’t run on an msp430 unfortunately...

Do you have incremental testing so that only what's changed is tested? If not that would be a better investment than new hardware, IME most shops don't have incremental testing.

For real. Compilers are lightning-fast compared to running even a subset of most test suites.

What if you're using TypeScript, creating a few packages, and bundling them?

then you probably only need a 486 or so? programs can manipulate text quite effectively using ancient cpus.

Clearly you have never used TypeScript, created a few packages, and bundled them.

Sounds like better tools are in order. Golang produces results instantaneously for example.

Almost no present software will run acceptably on a 486 since machines orders of magnitude faster are available at walmart for $300 the question of what software would is mostly academic.

In 1999 we were 'upgrading' to Evergreen 586s in K12 for a lucky few boys and girls. Good times and a lot of nothing going on. PIO4 and PATA with PCI buses clocked at 33 MHZ.

Can you imagine really trying to run 20+ year old tech in developer space? 8 - 10 MB/s throughput and 70 bogomips?