331–340 of 363 posts
Earlier quoted context omitted.
Instead of shower? No, you can't find a pool that cold. But I do always recommend jumping in to a pool all at once rather than wading in slowly.
I always like to dump a sewing kit into a pool before I get in, as such a thread pool is instantiated and multiple people can enjoy it concurrently.
Earlier quoted context omitted.
I hear this bad argument often (“replacing hard drives”) and I don’t understand why. It’s as if we’re mentally stuck in a bad hacking movie from 1999. If you’re doing colocation to save money, you’ve also figured out that going to the datacenter sucks and it’s a terrible place to do work. You’re not building your own servers from scratch, you’re generally purchasing them from a vendor who offers a warranty and option…
So you've just explained why 'the cloud' is better than DIY. Take all those things you just talked about, and expand them horizontally and vertically up the stack, and you have 'AWS'. So not just 'a guy to replace the hardware' - but now it's software configurable, has all sorts of other, fancy things. Time is money, and it's expensive to pay people to mess with things if they don't have to. It's like this: If your c…
Earlier quoted context omitted.
What if my company is pretty much all engineers? We don't let pencil pushers with MBAs anywhere near what we're doing, and it's going great. I know this isn't the most usual configuration but if undervaluing my skills and trying to bottom dollar on them is going to be their rules, then I'm just going to do my own thing, and they're just going to have to scrape the bottom of the barrel for talent. I hope the zeitgeist…
Maybe you need an MBA to help you understand that in many cases, it's incredibly more cost effective to use the cloud, because the marginal savings that could be achieved with on prem hardware are dwarfed by the cost of labour, and especially lost opportunity cost. For most things 'local prem' is an optimization that usually needs on some degree of scale to justify, or, you have a peculiar setup i.e. a couple of well…
Earlier quoted context omitted.
The people above you suck. That's a terrible attitude. Signalling that saving money or just generally improving systems doesn't matter will not build a culture of technical excellence and ambition. Also, it's not peanuts. How many extra developers are $28400 per month?
no idea of $ but say they'd get 5000€ a month (quite OK for most places europe), the company would need to pay out a bit more here (for some tax/social benefit things), 7000€ would be pretty realistic, so 4 developers could be hired. This then means that while op wouldn't immediately add 1M ARR, the original dev and the new devs could soon add 5M ARR (stupid extrapolation, it won't be as much in practice, at least no…
Earlier quoted context omitted.
Reduces bugs in size, or only leaves smaller bugs behind? These are two very different outcomes. If the remaining bugs are unrelated to the class of bugs that were eliminated entirely, then the difficulty in finding them has little bearing on the outcome, since we’re now talking about an entirely different class of bugs.
This is conjecture, but in my experience you'd get the following: - in JS, your code will run with the bug then do something catastrophic during runtime that you can then notice and trace to the core issue - in Java it won't compile, so you fix it so it compiles and runs, then it'll hit you in like 2 hours of runtime with a NPE or something and you'll have no idea what caused it Maybe Kotlin, Rust, and the like solve…
It seems you're describing an orthogonal issue, and it's unclear why type checking is a Bad Thing or even related to the NPE at all.
Let's say I work on an assembly line, and must place physical parts into a machine that assembles a larger part. There are many ways this machine can break down - I could put the wrong parts in, leading to a complete failure, or some part of the machine could malfunction independently.
- We could implement part validation on the assembly machine to make sure it's impossible to insert the wrong parts. This eliminates failures related to incorrect part insertion.
- Unrelated to this, a drive belt starts to wear out and slips every so often, leading to a slight slowdown in a conveyor belt, which ultimately leads to a botched item.
The way I read your argument, you would say that part validation is bad, because it's easier to diagnose a meltdown when incorrect parts are inserted by the operator than it is to determine that the drive belt is slipping.
Except the drive belt slipping is not related to operator error, and would have happened whether part validation was happening or not.
This is hopefully obviously nonsensical - better to reduce the overall error rate by implementing part validation than to leave two avenues for error. Before part validation, the machine could fail because of operator error (common) or drive belt failure (uncommon). After part validation, only the uncommon error occurs.
This is better than no validation at all, even if drive belt failure is harder to identify than the machine screeching to a halt when the wrong parts are inserted.
What am I missing?
Earlier quoted context omitted.
Haha! Back in ~2014 or so my company was spending nearly $30,000/month on an EC2 "compute-optimized" cluster to transcode live video streams to multiple renditions. One of our engineers said hey, why don't we try to colo some real hardware? We did a test with a single bare-metal 8-core Xeon server and it completely destroyed the performance of the EC2 "compute-optimized" cluster! After that we colo'd 4 big Xeon serve…
So you saved, $28,400 a month. Did that make a material difference to the company? I often tell people above me I could save us $10k a month at AWS and generally the response is, "Yeaaaaaaah that's great, could you do XYZ instead to help us land an additional $1M in ARR?"
ARR could be whatever. They are not interchangeable or mutually exclusive.
Earlier quoted context omitted.
I agree that cloud compute is usually (too) expensive, but it is sometimes useful and cost-effective. Not long ago, I need to very quickly run a one-off analysis, which required over 200 GB of RAM. It was much cheaper and faster to spin up one VM on GCP for a day than having to order parts, etc.
What was the price?
Overall a questionable list of unproven claims. E.g.: > Hype: "Static Typing reduces bugs." Just because the author has not found proper research proving it doesn't mean it's false. A great type system with sum types prevents tons of bugs. I wonder how anyone can question this. > Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." Same as above. To fix bugs you need to read and understa…
Some developers and teams don't need the crutches. Type systems are also an encumbrance that comes with a non zero amount of issues. They slow development velocity down for a theoretical trade-off boon.
I've seen a type system take down a production system where a simple coercion would have functioned just fine. Literally the only thing wrong was the type defined and the code refused to run.
Earlier quoted context omitted.
If it were an item id the argument would be item_id. It is an object. What type of object? The type that can be added to a cart. You don't just drop a programmer into the code and have them call a function in a vacuum. Nobody just throws random objects at a function. They are familiar with the code in general and they know what to do.
- If it were an item id the argument would be item_id. It is an object. You've never worked with vaguely named variables? What you are suggesting is guessing the data type based off the name. - What type of object? The type that can be added to a cart. Okay sure, but what precisely is that? - Nobody just throws random objects at a function. I couldn't agree more - so the follow up question is what is the fastest way…
It doesn't matter "what precisely" is the the thing that you are adding to the chart, and a static type system won't tell you that either. There could be be any of 1000 things that implement IItem. And probably half those things just throw exceptions for methods they aren't actually able to implement.
Earlier quoted context omitted.
s/gods/tests/ - which you need even in a statically typed system.
I don't need tests to check what methods or fields are on my types though. You need the same tests from a typed system in a non-typed. You _don't_ need all the tests from a non-typed system in a typed system. Writing tests to enforce types just hand-rolls a type system, in my experience.
You do though, because invariably people violate the LSP and just "throw Unimplemented" in the methods required by the interface they can't figure out how to implement. In other words all system are duck typed in reality.