[hn_throwaway_99]

I feel like I could sum up this article as "give engineers everything they want, they're expensive!"

TBH, I hate articles like this, not because I disagree with the general thesis, but because they present things in a way that is so one-sided that it is either ignorant or willfully blind to the other side of the equation.

Yes, I wholeheartedly agree that cost cutting or being stingy with resources can be counterproductive. But if you look at some of the top examples the article gives, nearly every one can have a flip side:

1."Tool penny pinching" - totally agree, having a good set of tools for engineers is critically important. At the same time, I've seen companies do an audit where they found lots of expensive SaaS products got little use or were not worth it. It's fair to say that individual tools should have to justify their costs in terms of productivity improvements or time savings.

2. Hardware savings - Unlike this article, I recall reading another good example of a midsize software company I believe where the engineers were just able to make a case that better hardware would save x hours per developer per year. It was an easy argument to management so they upgraded. That's much better than "We want the fastest laptop, just trust us!"

3. "Infrastructure Sabotage" - this is the one that I think annoyed me the most, because I've seen cloud costs explode where hardly anyone had a good grasp on where that money was going.

Yes, there is a reason "penny wise and pound foolish" is a well known saying. But this article is just heavy on the feels without ever making good, analytical arguments.

[pplonski86]

It is about the tools that you are using. The better the tool, the faster the job is done. I always get the best machine I can afford and never regret it. I'm working with data; I have a desktop machine with 256 GB RAM and 36 CPUs; it was expensive, but I can train huge gradient boosting tree models in a reasonable time.

[hn_throwaway_99]

Your response here is exactly what I'm talking about though. For you personally it looks like the choice obviously makes sense given what you're using it for.

But I've seen plenty of developers cry that they need 256 GB RAM and 36 CPUs to do React front-end development. My fundamental problem with this article is the author is showing they have no idea how business works, money is not infinite, and that if every department always got every top-of-the-line ask for their resources and tooling you could easily add a huge, unsustainable amount to your cost structure.

[brailsafe]

> But I've seen plenty of developers cry that they need 256 GB RAM and 36 CPUs to do React front-end development.

Seems a bit hyperbolic. I do front-end development, and upgraded from a 5yr old 13" MBP with 16gb of ram to a 16" M4 Pro with 48gb, and a second lesser M3 Pro for a client. Both are fantastic, and probably the minimum I'd bother trying to work with professionally, anything down to M1 Max would likely be fine, but anything older or with less ram might be too sluggish to be palatable, and it would introduce more friction than necessary. There's not much of a direct time savings to be argued for, but plenty of less obvious pain points that just add up and become irritating when there are better tools one could be working with.

[TimByte]

The thing is that the core message is that cost-cutting needs to be smart, not just reflexive

[HelloNurse]

Regarding tools and hardware, "trust my judgment and buy what I ask, or you'll also make great savings on my salary" should be a compelling argument. If it isn't, there is a social problem that runs deeper than wasting money.

[hn_throwaway_99]

> trust my judgment and buy what I ask, or you'll also make great savings on my salary

Baloney. I've seen tons of developers claim they need top-of-the-line everything, even if after some point it has no improvement on their productivity. And why not? I don't blame them, I'd want the "256 GB RAM, 36 CPU" beast the other commenter mentioned, too, even if I didn't need it.

I'm not at all saying this has to be an adversarial conversation. But, as people who like to call ourselves software "engineers", I don't at all understand the pushback to at least offering some sort of analytical justification when asking a business to spend gobs of money.

[HelloNurse]

I don't necessarily "need", I want my aggregate personal equipment to cost a large fraction of, say, my manager's company provided car. The justification is personal, not analytical.

Given a fixed high budget, it doesn't take much common sense to prefer something more useful (e.g. a spare laptop instead of a luxury chair and desk, or remote servers instead of some dangerous SaaS).

[roncesvalles]

It's about having taste. Some SaaS tools are obviously worth multiples more to your employees than their costs. Same with hardware tools like laptops, monitors etc. I'd throw in catered lunch as another worth-it expense.

It's about knowing which ones are worth it which aren't, rather than having a sweeping policy of either too much or zero bureaucracy to whatever an employee asks for.

[inglor_cz]

I spent a lot of time making ends meet in tight development budgets, deciding what can and cannot be done within our limited means.

Cuts are sometimes absolutely necessary, but you must never let yourself get distracted by symbolism. And managers often fail at that.

[anal_reactor]

I realized that the intersection of "understands computers" and "understands basic business management" is absolutely tiny.

[drewcoo]

People generally prefer simple messages. Presenting a richly detailed nuanced argument is a recipe for failure.

The biggest problem with that is that simple messages are all lies. Luckily most people would rather embrace a simple but catchy lie.

https://www.psychologytoday.com/us/blog/experimentations/202...

[CyberDildonics]

With a title like "Don't Be Frupid" it's probably best to set your expectations low.

[djkivi]

User name checks out?

[CyberDildonics]

How does that make any sense at all?

[TeMPOraL]

> 3. "Infrastructure Sabotage" - this is the one that I think annoyed me the most, because I've seen cloud costs explode where hardly anyone had a good grasp on where that money was going.

On the other hand, I worked in a place where the Change Request -> code review -> merge pipe took ~two days on average, and could sometimes span over a week, all because of ridiculous penny-pinching on infra. The CI build itself took 1.5h of which > 60% was testing. That was understandable, if not ideal. The problem was, however, that the whole infrastructure could support evaluating maybe 5-6 builds in parallel (20-ish runners, each build typically consuming 3 or 4, depending on type and platform configurations), and that was shared with automated tests (that run nightly), as well as all kinds of one-off release builds for QA, manual builds, etc. So it took two or three changesets being built in parallel before the next one had to wait on bots to become available.

Add to that a few flaky tests that would fail one of the builds for your changesets about 30% of the time for spurious reasons, and people submitting more patches (= more build jobs) in response to review feedback, and you can imagine what it did to work cadence. To top it off, there was a cultural push for "best practices" of small and frequent changes; of course doing that basically meant you were submitting changes faster than they were built, DOS-ing the build system for everyone else.

And, lord forgive you if you tried to submit a stack of commits at the same time. My co-worker and I both independently discovered that if you do a big enough stack (working on a large feature, broken down for reviewability), say 7-9 commits, not only you'll saturate the build system, but apparently OpenStack or whatever it was managing it would run out of resources and cascade failures to some other systems elsewhere in the company, because of course it would do that.

I've fought to get this improved since almost day 1 on that team, but it was always met with reactions from IT (later, "devops") along the lines of: "what is your problem?" or "yes, I know, but we don't have the budget" (seriously? compute is, and was then, almost too cheap to meter), and eventually stringing us along with half a year of "we're migrating to $BigCloudProvider, afterwards we'll have plenty of compute", which ultimately never happened before I left.

So I've seen first-hand how ffrupid (double "f" is intentional) otherwise smart companies with large budgets can get with compute for devs, even as this wasn't just destroying morale and preventing the team from adopting some good practices, it was actively slowing down project work, delaying both scheduled releases and emergency fixes.

[Dalewyn]

>It's fair to say that individual tools should have to justify their costs in terms of productivity improvements or time savings.

Indeed, and this is why it's often advised that people should buy their first set of tools at Harbor Freight (or any other store selling cheap tools, for the not-Americans).

If those cheap tools wear out or break from use, then you go out and buy the really good ones from Snap-on or Milwaukee and the like.

[ljm]

Does the author owe you a good, analytical argument? You were able to respond to it with your own experience easily enough. That's usually how conversations like these work.

[dxdm]

I don't understand what exactly you're criticizing GP for or what you'd like them to do differently. And then: do they owe you whatever you'd like them to do? Do you owe anybody a clearer argument? How many people do I owe time for reading this comment? I feel like you opened a can of mirrors. ;)

[ljm]

I'll just say that, when broken down into three parts, the middle part effectively engages with the post and is a valid contribution all on its own, and the first and last bits just seem pretty pointless criticisms.

The parent poster isn't exactly responding with their own thoroughly analysed thesis.

[dxdm]

Thanks for clarifying!