RussianCow

The problem is that there are so many free fonts that most people take them for granted. And honestly, I don't blame most folks for thinking that way because there isn't a good reason for the average person to pay for a font. If you're just making wedding invites or signage for an event or some other one-off thing, you probably don't care.

If you're a professional using them in your work, that's an entirely different story, and you are significantly more likely to appreciate the craftsmanship that goes into making them.

[citation needed]

In my experience, even simple CRUD apps generally have some domain-specific intricacies or edge cases that take some amount of experimentation to get right.

LLMs are still very young. We'll get there in time. I don't see how it's any different than optimizing for new CPU/GPU architectures other than the fact that the latter is now a decades-old practice.

> There's an argument that this is a trade-off vs increased IT support cost/workload, but I guess SWEs don't need much support to begin with?

IME, it's also about being able to ensure that everyone has access to the same software. I worked at a company that used macOS-specific software for development (I think it was Sketch?) so I had to have a MacBook around, even though I primarily used a Linux desktop for work. Anecdotally, I don't think this is uncommon.

If you're doing "dependency injection" by just passing arguments to functions/modules, you're not really doing dependency injection—you're doing "dependencies" without the "injection" part. I'm not saying that DI necessitates a ton of magic, but you need at least a small framework for specifying dependencies and injecting them into your modules dynamically.

I pay $10/month just to have search results that aren't littered with SEO spam. The time savings alone make it totally worth it for me. Everything else is a giant bonus.

> Does your desktop app need a gyro, webrtc and gamepad support?

I doubt those impose very much (if any) overhead for just being present but unused. In any case, those aren't the things that the OP was talking about; there are plenty of layout-related standards like floats that are almost never used in modern web apps yet inhibit or prevent many optimizations that could potentially significantly increase rendering performance. For a more extreme example, imagine how much faster layout rendering could be if you removed all types of layout other than grid—you'd be able to remove a bunch of checks and all the code that handles edge cases, significantly simplifying the happy path.

Nobody (to my knowledge) has done this because it's not as simple as forking Chromium and removing code. Without the mentioned optimizations, I don't think you'd see much benefit.

To be fair, most people just absolutely don't care about this stuff as long as it does its job, so it makes sense for them to use a cross-platform toolkit here.

You have to remember that, besides the extra engineering effort, having a separate, native UI for each platform also increases the support burden for dealing with people having issues with the program. Companies the size of Logitech bend over backwards to reduce their support costs, so it shouldn't be surprising that they opted for the path of least resistance here.

You're assuming most of that space is taken up by telemetry software. 100MB of that could easily just be the UI toolkit!

> You either can work with electricity wires or not, no third option

As someone who has used The Internet™ as a reference for more projects than I can count, I strongly disagree with this. There is definitely a middle ground where you know just enough to do some basic things on your own and feel comfortable venturing a bit deeper, but not without some help.

> It will not help you because bathroom fans may have different ways to disassemble them, car belts may have different bolts position etc.

I dunno, I can usually find at least one guide online for how to do a specific thing with a specific model of something. Search "change timing belt $year $make $model" and you'll get at least a handful of videos walking you through the whole process.

Having said all of that, this entire discussion is a bit moot because it's easy enough to download YouTube videos or tutorials locally ahead of time and pull them up on a tablet without internet access.

The latter at this point.

> All of which I've directly contributed to and never (directly) recieved anything in return

To be fair, you received a service for free that you may have otherwise had to pay for. I'm not saying it's just, but to say you didn't get anything in return is disingenuous.

> Exponential inner loops for big searches, huge recursive calls. Those things show up in code written by experienced coders IRL.

The thing is, those things are easily fixable after the fact. A bad architecture is not, and without practical experience designing systems in the real world, you don't have those instincts to guide you towards the correct choices because you haven't made any mistakes to learn from.

> They were late

This was the main thing, as by that point, all native code was being compiled to Arm and not x86. Using x86 meant that some apps, libraries, etc just didn't work.

Of course they do. The cost of the ingredients is on the order of cents, the marginal cost of labor negligible, and the cost of the machines can be amortized over many thousands of servings.

But even if they didn't, it's a cheap way to get people to show up and potentially order other, higher margin items. If your machine is broken, you lose that funnel and your customers go elsewhere.

> When you're using expo you cannot bundle your own native extensions. [...] You're locked to their prebuilt ones.

Unless I'm misunderstanding what you're saying, this isn't true at all. At $day_job we have an Expo app with a custom native library and it works just fine; you just have to write an Expo-specific adapter for it and can't use Expo Go in that case.

Source: https://docs.expo.dev/workflow/customizing/

How so? What makes this a game changer for the average dev?

This is extremely elitist and reductionist. Plenty of the best comments/discussions on HN come from non-programmers. Personally, I like that people from various backgrounds come together like this as it tends to provoke more interesting discussion and makes HN less of an echo chamber than Reddit.

> - You're able to ship a far more featureful application if you deal with media and/or VoIP

Can you expand on this? How does Expo prevent or make it harder for you to ship media- and VOIP-related features?

Presumably because most people don't know about F-Droid, and there's a question of whether it's worth continuing to develop the app for a tiny subset of the original audience.

At what point do you hit that scale with project management software, though? Maybe you can't get to the point where you're managing all projects across all of Walmart from the same instance, but certainly you can run pretty much anything of reasonable size.

Sure, and my Amazon example wasn't very illustrative of the kind of information that could be gleamed from tracking this at a more granular level. A more concrete example is that my wife and I were flirting with the idea of reducing our meat consumption (for non-financial reasons) and wanted to see what the financial implications would be. Another example is to try to accurately price out past trips we went on: some things normally get filtered under other categories, such as clothes or other products purchased specifically for the trip.

This level of granularity probably isn't worth it to most people, but I found it useful as an exercise to do once because it opened my eyes to insights about my expenses I never would have thought about otherwise. And if there were software that made this super easy to do (<1 minute per entry), I might still be doing it.

I did this exercise for a little over a year to understand my expenses in detail. Like the OP, I found it really frustrating to do with any bookkeeping software I tried, to the point where I eventually gave up as I didn't think it was worth the effort. I started writing a web app to make this easier but just didn't have the motivation to finish.

With that said, I learned quite a bit as a result of that level of granularity. When all expenses at Amazon, Walmart, etc go into the same bucket, it's really difficult to truly understand what you're spending your money on and if you have a problem you need to curb. Seeing "$X in spending at Amazon" isn't really that useful without knowing how important or frivolous any of those expenses were.

This is terrible advice. The non-technical founders who are struggling to find someone to implement their "great idea" are never[0] worth working for. It's not like you'd get a 50% share of the company anyway.

[0]: I'm sure exceptions exist. I've never met one.

Intuitively, I think most managers think that tackling everything in one go is somehow easier or less risky.

> When something breaks, having only 1 or 3 changes makes it really easy to figure out why. Recovering after a big release with 40 PRs in it is absolutely painful.

This is, by far, the most important reason to practice continuous deployment. I've been part of enough of these fire fighting sessions following big releases to see that it's not a sustainable way to deploy software. And yet, I've never been able to convince any boss I've ever had to adopt CD because they're worried it'll introduce more regressions into production.

But nobody follows the actual guide so it doesn't really matter.

For a single individual, all of the above is true, but for a large enough sample size, the answers may be more generally useful because you account for all of those rounding errors.

> I would actually find it more practical to determine the thresholds on both sides where I find it to become ambiguous.

Isn't that the point of this exercise?

I think it depends on your code and dependencies. At work, the time between making a change in our codebase (which is much smaller than a million LOC) to having ESLint update itself in the IDE can take 5+ seconds, depending on what you changed. But we also use some pretty over-engineered, generic-heavy dependencies across our entire codebase.