> Please state the location and include REMOTE for remote work, REMOTE (US) or similar if the country is restricted, and ONSITE when remote work is not an option.
We have preferences in terms of where we hire, but remote work is an option depending on the individual and where they are located.
I would clarify this in the HN post. As it is right now, it looks like this is a remote first role when the reality is it is a hybrid role. Just because you might be willing to make an exception doesn't make it a remote role.
I said what I meant in the original HN post. I would encourage folks with relevant experience and interest to apply regardless of location. The bulk of the current team, myself included, is remote and has been for years.
Are all of your positions like that, or only durable objects? I was always interested but the defined locations in the job descriptions held me back from applying.
This, like most parts of the application process, are team dependent at Cloudflare. I manage another team, Cloudflare D1, and I do not see myself hiring someone for that team that is not willing to do hybrid in Austin or London. The existing team works well being in the office.
“The job description says remote on HN, but it says hybrid Austin on the jobs page, but disregard that, it can be remote like I originally said. But also some teams are only going to be hybrid no matter what.
So some jobs are hybrid onsite and some are fully remote but even if i said just now that all jobs can be remote, some jobs aren’t really fully remote because I can’t envision it in my mind that they would be effective fully remote, even though I myself am fully remote.”
The stupid answer is that not everything that can be automated should be.
The real answer is of a more philosophical nature, if you manually had to check A, B, C... Z, then you will have a better understanding of the state of the system you work with . If something goes wrong, at least the bits you checked can be disregarded and free you to check other factors. What if your systems correctly report a faulty issue, yet your automatic checklist doesn't catch it?
Also, this manual checklist checks the operator.
You should be automating everything you can, but much care should be put into figuring out if you can actually automate a particular thing.
Automate away the process to deploy a new version of hn, what's the worst that can happen?
But don't automate the pre flight checklist, if something goes wrong while the plane is in the air, people are going to die.
I think a less verbose version of the above is that a human can detect a fault in a sensor, while a sensor can't detect it is faulty itself.
I'm not a pilot, but my brother is, and I watched him a bunch of times go through these before takeoff and landing. I think it's about more than automation, these days the aircraft computer "walks" the pilots through the checklists but it's still their responsibility to verify each item. I think it's an interesting approach to automation, keeping humans in the loop and actually promoting responsibility and accountability, as in "who checked off on these?"
Someone checks that they ran successfully, and vouches for it.
Automating the automation can be counter productive.
Like the release process is triggered automatically by a tag, then fails after an hour long sequence of complex steps, which forces you to re-tag, but by then your tag is out there.
Or, simply, it's a bad idea to run the entire process from scratch, but you automated it such that it's easiest, so you fix something about it and the only way to test the release process itself is to release, and you now need half a dozen releases to get it right.
They were "on the Python Typing Council and helped put together the spec, the conformance test suite, etc" so I assume they are an expert on Python typecheckers
reply