Don't Be Frupid(selix.net) |
Don't Be Frupid(selix.net) |
I now fly out of MCO where my choices are a layover or maybe flying Southwest. I don’t hate myself enough to deal with that “We are Sparta” boarding process.
Besides, I’m platinum Medallion on Delta…
Maybe I’m just crotchety but something about blogging your AI crud to the world really pisses me off. Feels… disrespectful, almost?
I hate slop as much as the next person, but I guarantee that this is just me.
Now obviously it'll vary by amount, but mostly we don't overthink it. We need x, we get x. Often we then use x, but occasionally it turns out we didn't need it. It's easy to look around the office and see a bunch of things we bought, but never used.
The point is, we can do this because it's basically "our" money. We aren't beholden to shareholders or (worse) an electorate.
We're seeing the flip-side of this in govt now. USaid is "on hold" because of wasteful spending. Yay, we dont won't waste. But that's like killing a business completely because you don't like the pens they chose.
Of course there's waste. It's impossible to spend money without it. Yes, it should be a small %. Yes not every purchase benefits everyone. But just killing it doesn't kill waste, it kills people. Lots of political points are earned because some payment in there is wasteful. No mention of the vaccine studies that are now useless, or the people half-way through a study who may be getting adverse effects (now with no support.)
In a business we call it Frupid. In politics it makes for z good sound bite.
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.
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.
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.
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.
Cuts are sometimes absolutely necessary, but you must never let yourself get distracted by symbolism. And managers often fail at that.
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...
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.
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.
I agree with the thesis in general but this point is not resonating strongly with me.
Conferences are expensive.
AWS reinvent for example requires you to spend 2000 dollars on a conference ticket and travel to Las Vegas and pay for expensive hotels etc.
Most of the content from the sessions and talks there is posted online on YouTube ... in recent memory they posted them online within a day (full credit to them).
The added benefit of attending conferences in person is very hard to justify IMO. Yes there is networking and yes there are some hands on workshops etc.
Instead of the justification offered in the blog post ... I would say, sponsoring your employees' visits to conferences shows that you treat them well, care about their personal learning and growth, and inturn motivates them to look for synergies between their interests and work. They might end up learning that technique from a free youtube video anyway, but only the motivated ones care about applying it at work.
The next week there were 40 staff queuing for coffee at every cafe within a 10 minute walk. Coffee breaks went from 3-4 minutes (walk to kitchen on your floor, press 'latte', walk to desk) to a minimum of 45 minutes (elevator to ground floor, walk to cafe, queue with everyone else, wait with everyone else, elevator back up). These were staff on high six figure salaries.
Definitely the Frupidiest decision I have ever seen.
My low-stakes conspiracy theory though is that cloud providers (and symbiotic entities in the ecosystem) have helped turn developers against monoliths in favour of self-serve microservice architectures and devops because there's a lot more money in it for them when people are spinning up dozens of hermetically sealed, over-provisioned services, each with their own DB, cache, load balancer, etc.
It's like corporate welfare, redistributing wealth from VCs to Bezos.
I agree with the general concept, but the example in the article are so extremely exaggerated that it’s hard to take the article seriously. A $15 tool that would save hundreds of hours of tasks? A conference visit that would save millions? Anyone who has had to approve, review, or audit expenditures knows it’s not that simple.
I was involved with a company that got a lot of funding during the zero interest rate era and adopted this idea that it was self-defeating to scrutinize software and hardware purchases. When the money stopped flowing they finally started reviewing software and hardware expenditures and found, unsurprisingly, a massive amount of unnecessary spending.
In the real world it’s almost never a $15 tool that saves hundreds of hours (like this article used as an example). Instead, it was countless SaaS platforms with per-seat licensing fees that added up huge recurring bills.
There was a recurring theme where some department would say they needed some SaaS tool, so it got approved. Then they would add everyone in the department and many people outside so they could share and access the links. Every time someone needed access, they’d add another seat for that person. Countless cases of teams spending $49/month times 50 seats times multiple years for a tool that nobody could even recall using recently. Multiply this by dozens of tools, some of which were very expensive, and the amount spent on unused SaaS seats could have easily funded multiple extra engineering teams.
So while I think it’s frustrating to have to petition to get purchases made, I’ve also seen the madness that happened when it’s a free for all. Gone are the days when someone would expense a $50 software tool and use it for years. Now it’s a SaaS with a recurring subscription that has viral tricks to get everyone who uses it to count as an extra seat for monthly fees.
Conferences are another area that can become a boondoggle very quickly. Don’t even get me started on the “conferences” that were actually just week long getaways with JavaScript influencers at some resort somewhere, with a couple presentations included so you could get your company to cover it.
The answer to all these questions is that things that are measurable will always be prioritised over things that are not easily measured. And the more mature the enterprise, the more the measurable has been squeezed to the detriment of the immeasurable.
IT hardware spend it very easily measured, but the time wasted and morale hit you get working on a shitty laptop is very hard to measure.
Anything that is measurable, you just turn a knob and announce 10% savings: well done you! enjoy your promotion -- the intangible negative externalities of your recklessness will rarely be considered or even known by the person whose job it is to review your performance.
Now I have a strong belief that paying people whose only job is to save on costs is a bad move: they will conclude that the best way to save on costs is to shut down the company. Technically correct!
Cost optimization + a lack of systems thinking = frupidity.
You need to approve the vendor, check if there no minimum amount of seats, then figure out that even for a simple sso they have a different plan which is 50 usd / month
And with laptops, I get the point to some extent, nobody says buy an engineer a 2 core 8gb ram machine, but try speccing up a Mac and see how deep the apple tax is on ram and storage, especially if you're non US.
I would propose, as always, things are about context and compromises.
I know you mentioned "outside the US", but inside the US, skimping on $1500 when you're already paying the developer $150k a year, plus benefits, plus the laptop already costs $2500 as a baseline seems insane.
Business travel in general seems to be rich hunting grounds for frupidity, because the bean counters aren't the ones traveling. The good old "can't expense anything without a receipt" policy, for example, ensures people will take expensive taxis (with receipts!) instead of tapping on and off public transport.
Business travel has a lot of potential for abuse too, though, so the restrictions can sometimes be understandable.
Conferences are often held at desirable destinations, allowing attendees to combine a business trip with a mini vacation. OTOH, I suspect that much fewer people would be willing to make some trips (that the company wants to happen) if there wasn't some personal benefit, because (I assume) most people don't particularly enjoy sitting on an air plane and living out of a suitcase.
To their credit, when I would email them and let them know that I found a cheaper direct flight, leaving at my preferred time, out of my preferred airport, they would graciously change the flight to that one.
But I'm not sure why I was required to do the legwork at all for a service they were nominally providing.
Highest end dev laptops available. Dev replicas of prod infra. Separate high spec servers for almost everything. Highly automated deep testing pipelines. Enterprise grade Internet.
We also shared how to build 2x-10x faster github actions runners: https://words.strongcompute.com/p/maximising-github-actions-...
Dev time is precious.
Other focus is Management by Context: Solid physical and tech environment. Clear goals of next feature with real testing in front of users. Dive into details where something isn't working, otherwise hands off.
The hard thing is knowing which ones are which. You can't see the benefit in advance.
A lot of things aren't worth paying for. A lot of software licenses go completely unused. A lot of conference attendees hang out with friends and learn nothing useful. A lot of modern hardware is spent editing CSS files.
The engineers exaggerate and say everything is useful because they don't want to lose any perks. The accountants exaggerate the other direction because their job is to protect cash flow and they have no clue what's useful.
Budget makers are often stuck in the middle: too far up to know what's practically useful but close enough that they know they need to make some investment.
A company I worked at had an IT budget of 5000 euro for 120 people (90% SWE). The logic was: if we buy a commercial solution for time tracking our IT budget will double. Instead super senior engineer Y is maintaining his "free" in-house solution with half the feature set.
All of these problems are about not taking the cost of expensive engineering time and energy into account in a rational way.
This has so many angles to it. You can't just generalize cloud costs. You can stop using bloated JS frameworks to make up for the inflated application costs. You can switch to OVH or Hetzner or better yet, on-prem. It's like you are asking everyone to just give in to horrible tactics of AWS
I'd add 'sending work staff on long flights in economy expecting them to hit the ground running and work straight away' but I have sympathies with companies facing 30%+ rises in travel costs.
This was incredibly timesaving for all those cases where you need a cable or a USB stick or a book or some parts off Digikey or a small software license. Because having a meeting about whether or not something is necessary would easily have consumed more than £100 of time.
It helped that it was a small office of less than ten people and everyone could physically see everyone else's desk.
It’s not too different to a design doc. Design doc proposes a solution and details the investment needed to bring it into existence.
Main difference is the additional need to communicate why there is a problem - but most design docs restate this at the top anyway.
Maybe making a case for a change will show the org some previously untracked info, eg. time wasted. And maybe that was not known previously and surfacing it leads to rapid change. But be wary because maybe making your case will cause you to learn things you didn’t know. You might make your case and learn there are reasons for the frugality that you weren’t privy to and now are. But going through the process will either way better align your priorities to the org’s and vice versa.
But also, I spent almost 2 years developing with 8GB of RAM. Constraints can help you develop and understand the problems better. At various times frustrating for sure.
I’ve never understood why companies don’t ask what laptop you want instead of shoving one at you. You’re hired for your expertise and then almost instantly given a hammer when you work with wrenches.
If you didn't have to look that up then chances are you've been somewhere that's frupid. :D
These principles get drilled into you repeatedly, through new hire orientation, interviews, etc. In particular, you get evaluated against the principles in your annual review, so it's important to try and find ways to say that you have worked by them.
So when you look around and see everybody trying to apply 'Be Frugal' by penny-pinching on unimportant things, or refusing to buy software and thus spending hundreds of hours in dev time, it's quite natural to rephrase it as 'Being Frupid'.
https://www.businessinsider.com/amazon-employees-use-frupidi...
As much as I’ve enjoyed employer-sponsored conferences in the past, I have to be honest that it seems like very few people are there to learn and come up with ways to help their employers.
It feels like an open secret that people go to conferences primarily for networking and finding other job opportunities to trade up to.
It’s actually a common recruiting strategy to go to conferences and find people looking to find new jobs.
I enjoyed my trips, but I learned very little.
But the vast majority of large company payrolls are stacked with 9-5 types who clock in, clock out, go home to spend time on anything not related to their job. These types don't read HN, don't watch engineering YouTube, don't read r/programming, don't read Slashdot, etc. If a company wants these people to skill-up, they need to do it on company time, and they need to bring someone from the outside to bring in outside knowledge.
Conferences are basically just an easy way for companies to outsource this, and companies will prefer to pay for conferences like re:Invent which will showcase vendors who got stuff like SOC2 to ensure they will pass Compliance, Legal, and Procurement, and not for conferences like FOSDEM which will help people build stuff that Only One Person Understands And Therefore We Can't Maintain It.
I assure you, HN has plenty of us stupid, lazy and incompetent people.
I think you mix two types of employees. There is nothing wrong with being a 9-5 guy. Doesn’t mean they don’t inform themselves on HN etc.
Your example sounds more like the type who just does what they’re told and nothing more. I don't know if this type would benefit from a conference or if a learning course wouldn't be more suitable.
on the other hand, some read to distraction...
I worked on a great iOS team at a FAANG where during WWDC we had scheduled time to watch as many talks as we wanted and then an EOW meeting to deep-dive into what we'd learned. It was our lead's idea and management was in full support, when I joined the team they'd been doing it for years. Shipping code was optional that week, the stated goal was just to absorb as much as possible.
The privilege was being able to use our good, fresh, caffeinated engineering time on real learning. When I was in college I could do 8h of homework and then watch lectures at 9pm, at this point, not so much :)
If it's a specialized industry specific users group where people in the same type of role swap operating experience, that's worth it. I.e. a heavily regulated industry where the safety of the public is involved like nuclear power, air planes, oil, etc.
The other type of conference is if your plant is specifically on a certain vendor for your core process. So automation firms for industrial controls conferences fit this bill If you're a Honeywell shop, go-to Honeywell users group, Allen Bradley go to process solutions users group, or anything with aveva going to aveva world.
If the production of your plant is dependent on the lifecycle of a vendor for parts, support and licenses, this type of conference is a must.
For both of these types there is a smart option to save a ton, volunteer to present. Most of the time if you present something worthwhile at a conference they waive the fee.
> AWS reinvent for example requires you to spend 2000 dollars on
That's an extreme example. There's thousands of other, more local, less expensive, less extravagant conferences. It's more for show than useful for the attendants, especially with the YouTube recordings. Anyone who can gain thousands or millions from new ideas in AWS also has TAMs ready to relay the interesting parts of reinvent during regular meetings.
Things conferences are useful for:
- exposing you to new ideas
- letting you interact with others in your community
- carving out time to learn
The last one is really important. Sure, I can watch re:invent videos on YouTube, but will I? Having focused time that isn't interrupted by normal work (or, minimally) is a great luxury that conferences afford.
Yep, that's a paid vacation for SF engineers.
some really dark patterns: block purchases (for ex. you can only buy 100 licenses, not 49 or 52), mandatory "upgrade" for security features like SSO, mandatory licenses for people signing up for accounts that you didn't specifically ask for, and the worst is asking for the "enterprise" plan (with egregious minimum license counts, even if you just use 50) in order to control / admin accounts (so you can audit for exited employees, etc).
the pattern is usually like you said, someone tries a tool for $10/month, and then gets their team on it, which let's say is 10 people. not bad. Then it gets out on the grapevine and other teams want to try - goes to 50 people ok still ok.
but then the sass vendor start using dark patterns and all of a sudden you're getting a bill for 1000 accounts (sorry, can't sell you any less!) at the "enterprise" price of $100/account/month.
and now you're fighting with the sass company to actually disable accounts of people who left instead of just keeping it "greyed out" but still visible, you just can't log in and can't control it ....
Not a software tool, but a $15 VPS on Hetzner or such would absolutely save hundreds of hours of tasks in the case I described here:
https://news.ycombinator.com/item?id=43000114
Even better, you could add a few more $15 boxes to quintuple the savings before it would make sense to look for another thing to improve. And better still, $15 is just a generic VPS price I pulled off the top of my head, you could do it cheaper if you tried.
They didn't even want to try.
An example: Figma [0]
[0] https://fasterthanli.me/articles/just-paying-figma-15-dollar...
I wouldn't agree exactly with the article, in that while it's very easy to start making decisions that are genuinely ROI silly (all companies make them, my current one not excluded) there is a balance between just paying without question and adding friction that encourages good decision making.
But in our case, getting the data wasn't too much effort, and helped inform us for a subsequent batch of hardware purchases. It ended up representing about $50k of spend that we'd like to allocate well, and took me a couple of days to investigate and write-up: my day rate means that was well worth it.
Their spreadsheets look good after all.
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).
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.
The parent poster isn't exactly responding with their own thoroughly analysed thesis.
But, the idea that you can just move workloads to a random VPS and get the same benefits of AWS/Azure/GCP is …naive and shows a lack of understanding of how any real company operates.
The last startup I worked for had 60 employees and we hosted microservices that aggregated public and private (to the company not PII) health care data for health care providers. They used them as backends for their internal processes and public websites and mobile apps.
We had to be scalable since any new provider could increase traffic by 10-20% and that helped when COVID came around in 2020 and traffic spiked
We had multiple MySQL databases, ElasticSearch, ETL processes using Lambda, CloudFront (CDN),S3 for storage, SQS (messaging), ECS (Docker orchestration), VMs for some workloads.
Should we have put those on some random VPS and spun up the equivalent for ourselves ?
Yes, I know how to do infrastructure outside of cloud. I started my career where half my job was managing all of this on prem - as in a raised floor in the same building - before AWS was a thing.
Everyone who throws together a website and hosts it on Hetzner shouldn’t be considered a “startup”.
I am on an m3 air though, which is not necessarily a weak machine and can still hold it's own in no-network areas for light work.
One of my early managers (based in Asia) saw his annual two-week business trip to the Bay Area as one of the most valuable perks of the job. He even brought his family along a few times (he paid for their travel obviously, but they probably shared his hotel rooms).
Personally I also enjoyed some of the C++ talks, but I had no obligation to attend them.
For what it’s worth, there are indeed solo operations running on a single VPS with $USD1m+ turnover. What are they? Hobby projects?
In the scenario I listed about my last startup, it would be silly to host those on a bunch of VMs and not use managed services even if they are hosted versions of open source software. The management of infrastructure takes too much time once it gets necessarily complex and doesn’t add. Skid to the business
There are relatively few SaaS products that actually need five nines of uptime.
And sure, you might think one approach is silly, but that’s just your opinion. The fact that there are plenty of startups not doing things the specific way you personally think they should be done is not a matter of opinion.