aspir

100% agree. Most of the time, when I hear "this could have been an email," it's from someone with a track record of not reading (or writing and responding to) emails meaningfully.

Fastly | Software Engineers (Senior, Staff, Principal) | US, UK, EU, APAC ONSITE PREFERRED | Full-time When you look at the headers of major websites, you’ll see us. If it has to be performant, secure, scaled worldwide, and always-on, it uses Fastly.

We're a global edge cloud platform for performance and security, emphasizing open standards, sustainable engineering, and resilience-by-design.

We're hiring across compute, security, platform engineering, network and edge protocols, release engineering, network architecture, client services engineering, and more.

Onsite preferred, but remote candidates with a strong fit are welcome!

Rather than building walled gardens, we co-founded the Bytecode Alliance, heavily upstream our work to open standards, actively author IETF drafts, and power the global infrastructure for open-source Python, Rust, Ruby, OpenStreetMap, and much more.

* The Stack: Rust, C/C++, Go, Javascript, Typescript, WebAssembly (Wasm/WASI), Wasmtime, Cranelift, eBPF/XDP, QUIC, HTTP, TLS, TCP, Varnish/VCL, Linux kernel internals, distributed systems, professional services. * Apply: https://www.fastly.com/about/careers

Yeah The Who's hiring format isn't a perfect fit for how we have it structured. In general, engineering can hire remote first if there's a good fit, and we have local entities or EOR processes for every EU country (to the best of my understanding)

> In terms of the style of reasoning, of the futurists reviewed, he's probably closest to Kurzweil, in that he uses numbers to give a kind of aura of credibility, but if you know something about the topic he's discussing or look at the numbers, the reasoning falls apart.

In one of his posts a few months ago, he went on a weird tangent about the CEO of ServiceNow talking about sales planning and whether his teams are "on plan" or not. For people who haven't spent time in or around sales, this is an extremely common shorthand for quota tracking.

Ed's rant about how impossibly weird and inhuman the framing was revealed how little he knows, and cares to know, about the mechanics of the businesses he claims to profile. Yes, something like "on plan" is jargon, but a shred of reasonable journalistic curiosity (a Google search) would explain what it means and how it's a normal statement for a career-sales CEO.

*Fastly | Software Engineers (Senior, Staff, Principal) | US, UK, EU, APAC ONSITE PREFERRED | Full-time*

When you look at the headers of major websites, you’ll see us. If it has to be performant, secure, scaled worldwide, and always-on, it uses Fastly.

We're a global edge cloud platform for performance and security, emphasizing open standards, sustainable engineering, and resilience-by-design.

We're hiring across compute, security, platform engineering, network and edge protocols, release engineering, network architecture, client services engineering, and more.

Onsite preferred, but remote candidates with a strong fit are welcome!

Rather than building walled gardens, we co-founded the Bytecode Alliance, heavily upstream our work to open standards, actively author IETF drafts, and power the global infrastructure for open-source Python, Rust, Ruby, OpenStreetMap, and much more.

* The Stack: Rust, C/C++, Go, Javascript, Typescript, WebAssembly (Wasm/WASI), Wasmtime, Cranelift, eBPF/XDP, QUIC, HTTP, TLS, TCP, Varnish/VCL, Linux kernel internals, distributed systems, professional services. * Apply: https://www.fastly.com/about/careers

Fastly | Software Engineers (Senior, Staff, Principal) | REMOTE (US, UK, EU) or ONSITE | Full-time

When you look at the headers of major websites, you’ll see us. If it has to be performant, secure, scaled worldwide, and always-on, it uses Fastly.

We're a globally edge cloud platform for performance and security, emphasizing open standards, sustainable engineering, and resilience-by-design.

We're hiring across compute, security, platform engineering, network and edge protocols, release engineering, network architecture, client services engineering, and more.

Rather than building walled gardens, we co-founded the Bytecode Alliance, heavily upstream our work to open standards, actively author IETF drafts, and power the global infrastructure for open-source Python, Rust, Ruby, OpenStreetMap, and much more.

- The Stack: Rust, C/C++, Go, Javascript, Typescript, WebAssembly (Wasm/WASI), Wasmtime, Cranelift, eBPF/XDP, QUIC, HTTP, TLS, TCP, Varnish/VCL, Linux kernel internals, distributed systems, professional services.

- Apply: https://www.fastly.com/about/careers

Fastly | Software Engineers (Senior, Staff, Principal) | REMOTE (US, UK, EU) or ONSITE | Full-time

When you look at the headers of major websites, you’ll see us. If it has to be performant, secure, scaled worldwide, and always-on, it uses Fastly.

We're a globally edge cloud platform for performance and security, emphasizing open standards, sustainable engineering, and resilience-by-design.

We're hiring across compute, security, platform engineering, network and edge protocols, release engineering, network architecture, client services engineering, and more.

Rather than building walled gardens, we co-founded the Bytecode Alliance, heavily upstream our work to open standards, actively author IETF drafts, and power the global infrastructure for open-source Python, Rust, Ruby, OpenStreetMap, and much more.

The Stack: Rust, C/C++, Go, Javascript, Typescript, WebAssembly (Wasm/WASI), Wasmtime, Cranelift, eBPF/XDP, QUIC, HTTP, TLS, TCP, Varnish/VCL, Linux kernel internals, distributed systems, professional services.

Apply: https://www.fastly.com/about/careers

At this point, the thread has over 700+ comments, but if any impacted Cloudflare folks see this and are interested in working on the same shape of problems, Fastly posted our "Who's Hiring?" for May at this link https://news.ycombinator.com/item?id=47975839

Happy to answer any questions, though I only check HN about once a day.

How I've starting using the ForeverNotes model on top of Apple notes as a lightweight note tracking system, only to slowly extend and evolve it via various AI tools until I build a full scribe / second brain system

We didn't want to get too wordy with a post like this. But to be honest, if you are knowledgeable enough to spot that kind of gap, you might be a perfect fit for what we are working on ;)

Fastly | Software Engineers (Senior, Staff, Principal) | REMOTE (US, UK, EU) or ONSITE | Full-time

When you look at the headers of major websites, you’ll see us. If it has to be performant, secure, scaled worldwide, and always-on, it uses Fastly.

We're a globally edge cloud platform for performance and security, emphasizing open standards, sustainable engineering, and resilience-by-design. We're hiring across compute, security, platform engineering, network and edge protocols, release engineering, network architecture, client services engineering, and more.

Rather than building walled gardens, we co-founded the Bytecode Alliance, heavily upstream our work to open standards, actively author IETF drafts, and power the global infrastructure for open-source Python, Rust, Ruby, OpenStreetMap, and much more.

* The Stack: Rust, C/C++, Go, Javascript, Typescript, WebAssembly (Wasm/WASI), Wasmtime, Cranelift, eBPF/XDP, QUIC, HTTP, TLS, TCP, Varnish/VCL, Linux kernel internals, distributed systems, professional services.

* Apply: https://www.fastly.com/about/careers

This is an unfortunate state of all open source. The entire economic model is broken, but PSF is one of the better operationalized groups out there.

Not to completely change the topic, but to add context, the Ruby Central drama that has unfolded over the past few weeks originally began as a brainstorm to raise ~$250k in annual funds.

This isn't good for the PSF, but if these "poison pill" terms are a pattern that applies to all NSF and (presumably) other government research funding, the entire state of modern scientific research is at risk.

Regardless of how you, as an individual, might feel about "DEI," imposing onerous political terms on scientific grants harms everyone in the long term.

Disclaimer: not only am I a Fastly employee, I'm the Fastly employee quoted in the register article originally linked.

We'd argue our stance and focus are a bit different. Our stance is -- we help eng teams and the open web with whatever their preference for AI might be.

If you want to go all in and monetize AI traffic or sign an agreement with a foundation model for training, we have tools that can help you do that. If you want to go scorched-earth on AI bots that try to scrape your systems, we can help you do that too.

It's all about helping engineers tasked with tough problems get their jobs done, regardless of whether the flavor of the week is AI or something else.

The story in the editor's note is charming enough that it's worth calling out:

>Thanks to UC alumnus Luama Mays, JD ’66, for sharing a copy of the declaration with UC Magazine. Mays was a pilot who befriended Armstrong while the former astronaut was teaching at UC and Mays was running an aviation company. Initially Armstrong called him, without even identifying himself, asking for a ride on Mays old "bubble-style" helicopter left over from the Korean War. It was exactly what Armstrong had trained on in preparation for operating the lunar module.

Optimistically, only 5% of the things that AI is bolted on to today will provide any value over time (which is better than the 0% rate for Blockchain a few years ago). My exhaustion comes from having to constantly sift through the fluff to find the promising aspects.

I will say -- a higher-end bot detection service should provide paper trails on the block actions they take (this may not be available for freemium tiers, depending on the vendor).

But to your point, the real kicker is the "many sites aren't going to get feedback from the real people they've blocked" since those tools inherently decided that the traffic was not human. You start getting into Westworld "doesn't look like anything to me" territory.

Yeah, I definitely don't want to pivot this thread into a product pitch, as the important thing is helping the open-source projects, but we can work with the maintainers to tune the systems to be as strict/lax as preferred. I'm sure the other services can too, to be fair.

Just a callout that Fastly provides free bot detection, CDN, and other security services for FOSS projects, and has been for 10+ years https://www.fastly.com/fast-forward (disclaimer, I work for Fastly and help with this program)

Without going into too much detail, this tracks with the trends in inquiries we're getting from new programs and existing members. A few years ago, the requests were almost exclusively related to performance, uptime, implementing OWASP rules in a WAF, or more generic volumetric impact. Now, AI scraping is increasingly something that FOSS orgs come to us for help with.

200GB and 2 Million monthly requests; Unlimited L3/4 DDoS mitigation; WebSockets and Push Notifications; K/V store

Is that what they already did? https://www.nytimes.com/2021/05/05/business/peloton-recall-t...

Salesforce development. There's a real learning curve, but Salesforce provides really good teaching academies and certification processes.

For an enterprise company, there is no data more important or highly valued than the CRM. Also at a mature company, sale motions are already dialed in, and comp plans typically only change 1-2 times a year (more than one change a year is bad for org morale). Large overhauls can be a pain, but they're extremely infrequent and ideally scheduled well in advance.

Once the system is operating and the daily, weekly, monthly, and quarterly cadence reports are dialed in, you just need to make sure the system continues to run, and deal with any special odd projects or reporting requirements from the sales execs you're working with.

Your sale exec partners have every incentive to get their processes right the first time, and rarely change them -- change disrupts any team (not just engineers), only with sales teams, that change results in tightly trackable lost revenue.

Its not "zero work", but it fits the "2 hours of active work, then chill" requirement. You'll have a busier end of quarter, but the first 2-3 weeks of the quarter will either be crickets or greenfield work.

Edit: this role can legitimately be fun too. You're at the nerve center for how the company actually makes money, and you get to have a cross sectional view of all other functions as a result. You'll see "how the sausage is made" but you only have to report on it and build the tracking systems -- you're not on the hook for performance or output. Also, sales people know when they have a good CRM process and are some of the most grateful folks in the world to those who help them. If you do a good job for your users, you'll be getting public shoutouts every day.

One answer - It's much, much harder to build and operate a global network infrastructure that it might seem. It's also even harder to invent some sort of "killer feature" or other genuine innovation on the experience. You're likely not using Cloudflare simply for commoditized pipes alone, but for other features or designed experiences in their offering.

A second answer - there are a bunch of bottom-barrel commoditized pipe services. You likely haven't heard of them because they're so generic. They've existed before Cloudflare, and more will be created in the future https://www.citrix.com/products/citrix-intelligent-traffic-m...

What you're proposing is testing two different variables in the same experiment. To dial in nutrition research, it's more traditional to control kcal count and test different nutritional quality, or control quality and vary kcal content.

I'm an amateur olympic-style weightlifter with a similar schedule to yours, and after trying every trick diet in the book I've come to the same conclusion. The only real advantage I can see from diets like paleo, keto, etc. is that they can make the average person feel satisfied with less calories. Also, processed high carb foods tend to be surprisingly high calorie bombs. But, it all comes down to cals in vs cals expended.

The discussion around _quality_ of calories, the mix of macronutrients for performance, etc is an entire separate can of worms.

I dunno, that sounds pretty good honestly. The only info I have on AWS's service is testimonials, so I don't have anything concrete.

The industry we obsessively study/studied was hospitality, where service is literally the differentiator between the "pretty good" and the "absolute best in the world," and we've been pretty meticulous about iterating and building upon our service ecosystem (it's way beyond just one team at this point) like one might do with a software product. Most of our customers, from the small ones in the early days to the huge internet juggernauts we've had the privilege to work with use us as the standard to which all other vendors are measured, sometimes quite literally in a very odd way. So, I don't know if we got lucky with some stinker incumbents, or we stumbled on to something completely different, but we've got a good system in place that's built a pretty solid competitive moat.

I guess if folks on the thread are still reading and interested in replicating this at their startups, my advice is: study elite hospitality and restaurants, not tech. I'm very rarely impressed with the service ecosystem in the tech world, though it happens, but I can learn something massive every day from hospitality.

I work for an competitor to an AWS product. We've grown rapidly over the past ~7 years in a generally competitive (lots of startups, some really old tough incumbent companies). Without revealing too much on our end, here's some lessons learned:

* AWS is bad at customer service, even for their large or premium customers. If you position yourself, and _seriously_ invest in making your company's culture rooted in exceptional customer service, that's a foothold.

* Don't compete on price. This is hard for most tech startups, as pricing is a very difficult thing to do properly, but resist the urge to drop price to compete. You'll never have the scale, the supply chain masterminds, or the financial modeling to compete with AWS on price, so position yourself as a premium or luxury offering and don't be afraid to price accordingly. If you do the first step properly (a deeply rooted culture of service) you'll be able to justify the price.

* AWS has great uptime, but often the actual operating performance of their service isn't that great, especially when you push the products beyond the 80% use case. They know that for the majority of their customer base, best-in-class performance isn't actually business critical (despite how flashy it sounds). However, there is absolutely a market for people who truly need best in class performance, or product flexibility, or some other best-in-class trait (latency, interaction design, etc.). Find who these people are, and optimize for that ruthlessly. This focus, in combination with the culture of exceptional service and positioning your brand as a premium provider, puts you into a completely different market space than AWS.

Slack is going to have to do a better job of educating new users as they grow. Assuming that these large, traditional enterprises will know how to use the tool without some sort of guardrails or deeper education will be problematic and likely hurt long term adoption.