Honestly, after ~13y in this, I only know a handful of items from the famous latency table, notably those I've used a lot (mutexes cost 25ns, is only 1/4th of main memory reference tho, then disk seek is x100K of that). I'm "DevOps" (and titular variants thereof) in most of my resume.
That said, I'm not above your bar as each cloud provider have their own pricing model. I'm not even above your bar for AWS---which I've used the past six years---just for the sheer diversity of their offerings, not to mention regional variations. I know how EC2 servers are priced relative to each other but when we include ECS, DynamoDB, Lambda, etc., I'm gonna need a cheat sheet.
It's not clear to me from the article how Mantle was porting the build scripts, infrastructure config files, etc across languages. Typically these files don't cleanly translate from one framework to another. Was this considered as part of 20% of project for human engineering effort?
No. Designing a system that is always up and running and can process small amounts of data constantly is a completely different problem from designing a system that runs occasionally with a lot of data. For one thing, your output formats are usually different in the latter case (maybe you're creating a PDF for example). Also the high availability requirement just makes things different at the design level.
Finally, the author claims it's not hard to switch between batch and streaming. With a large volume of preexisting data, this is just not true. For example, if you make a REST API call for each document in a DB, it can take days or months to load that. If batching together documents isn't a possibility, how do you move data between stores easily? (This data movement is often required when switching between batch and streaming.)
I'm seconding this, and I have first hand experience in exactly this problem, in finance. My first boss also had the view that "batching is a special case of streaming where you stream N and streaming is also a special case of batching where the batch size is 1 and so it doesn't matter which one you implement". This was never performant enough and he was eventually asked to leave.
The key is working incrementally, not sitting idle for months and then hammering production as hard as possible trying to get all the deferred work done in exactly one batch.
It's certainly true that LinkedIn is the go to for white collar professionals seeking to make their resumes visible passively to recruiters. But isn't life still easier with LinkedIn than in the before times, when recruiters would dig deep to get folks' phone numbers and then have to call each of those people individually? (I think the modern equivalent would be email addresses.)
It's true that LinkedIn makes recruiting much easier to scale to a mass market. And it's also true that it has a monopoly on that scaling for professional employees. But is it fair to call them an economic termite when it's still possible to do sourcing in an admittedly clunky and old fashioned way? Just because they have a monopoly on scaled recruiting doesn't mean that they hold all the cards the way Linde (also in the profile) would in the gas market. This is particularly borne out by the existence of Indeed or Stack Overflow as options for posting your resume for recruiting.
Maybe it is, maybe it isn't. It's not the point. Lawyers tend to puff their smokescreens, convincing people antitrust agenda is difficult. It isn't. Once you start eating a certain amount of the pie, the rules of the game change for you, and you only, because you become too strong, causing imbalance and threatening stability.
I'm sure LinkedIn's legal department employs an army of antitrust specialists frequently dealing with accusations from their competitors. That's a good thing.
There's one position you never wanna be in: When you don't have a choice, and it doesn't matter whether you're a company or an individual. Autodesk is one prime example of a long-term nasty sales behavior significantly distorting the market. Last but not least, democratic governments around the globe have been failing to enforce these laws, not to mention these are in many cases too permissive in the first place.
I wouldn't use Stack Overflow as an example of the market not being viable. 2022 SO had a horrible reputation problem, and their main value proposition (that is, qualifying the candidates) used a metric that was completely broken and probably counterproductive in practice (but we can't know that one for sure).
Is there someone on HN who can speak to how fast gene editing technology is improving? I was a bit skeptical of the author's claim that construction of a mammoth genome would require 5000 years, but I couldn't find any information in a cursory search on what the technology improvement speed is.
Well it used to take ~infinity years as the technique didn’t exist to do it at all.
Claims like “it’ll take 5000 years” are always funny because they’re so incredibly status quo biased, without the least bit of self consciousness of how remarkable the progress has been in the last 50 years on things like this.
Humans overestimate progress in the near term and underestimate progress in the long term.
Had a lot of spammers with Russian language. Implemented expanding xml-bombs, Google Captcha, hidden input fields and a couple of other things against bots.
But the block on the russian language was most effective ( and since I was dogfooding it, I didn't see the harm at the time. But it's out of scope at this very moment, yes).
I'm a fairly junior engineer at a subsidiary of one of the big 4. Before that, I was at a well-known big box store working on a few different projects.
The most impactful thing I delivered at my previous company was a script that moved all of our team's data from a self-hosted db to something on company cloud that was a lot more stable. The script itself wasn't very complicated (essentially just mongodump and mongorestore), but it made a big impact on ensuring that our team's dataset search tool would continue to be accessible to regulatory compliance folks. In turn, the regulatory people could use the tool to protect the company from getting fined under CCPA, etc.
It made a pretty big impression on me that something incredibly simple like that could make as much financial impact in expectation as that script did. Now when I mentor interns and newer, more junior people, I always tell that story as an example of how high impact can be surprisingly uncomplicated.
