Are they not worried about people seeing the joke requirement in the job spec, just not being aware of the current Twitter joke of the day, and discounting themselves?
No, it's selecting candidates who are aware of the current Twitter joke of the day. They're either unaware of how small that bubble is or accepting of the monoculture this promotes.
I'm sure people who are not aware will just search for it in their favorite search engine and find out it's a joke.
What it might filter out are people who don't find this joke funny, and might decide not to apply (and on the countrary it will catch the attention of people finding this funny and concluding Signal must be a cool place to work).
Getting devs attention on a job offer is hard these days, so I guess spicing it a bit is fair.
I, for one, wouldn't bother searching for a technology that I've never heard of if it were listed as a requirement for a job posting. I would just move on to the next posting.
There are too many jobs that I am qualified for to bother taking time for a deep dive on a job that I'm not qualified for.
To be honest I haven't ever actually looked for a job, but if I happened to read that annonce, I would absolutely check out wtf is that tech that is a requirement to work at signal, out of pure curiosity.
Also it probably depends whether you have actually used some aws services. I have searched quite a lot of aws services before, and not finding the product page straight away is a pretty good hint.
The thing is they change/deprecate/retire paid-for services too (in a brutal contrast with the competiton).
Two quotes from one of the posts referenced in the submission (from Steve Yegge):
...I know I haven’t gone into a lot of specific details about GCP’s deprecations. I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to… I dunno, everything, has forced me to rewrite it all after at most 2–3 years, and they never automate it for you, and often there is no documented migration path at all. It’s just crickets. And every time, I look over at AWS, and I ask myself what the fuck I’m still doing on GCP. ...
... Update 3, Aug 31 2020: A Google engineer in Cloud Marketplace who happens to be an old friend of mine contacted me to find out why C2D didn’t work, and we eventually figured out that it was because I had committed the sin of creating my network a few years ago, and C2D was failing for legacy networks due to a missing subnet parameter in their templates. I guess my advice to prospective GCP users is to make sure you know a lot of people at Google… ...
On the first, I've worked as a PM on Firebase, App Engine, and Endpoints.
Nobody has been forced to migrate from the Firebase RTDB to Firestore (and AFAICT the Firestore API hasn't deprecated anything?), App Engine deprecations (https://cloud.google.com/appengine/docs/deprecations) are basically "you can't do new things using these old things, but the old ones will continue to run" (though other deprecations I've done have provided clear explanations of why we're deprecating and how someone can work around it), and Endpoints is still around despite being comically out of date (it's even getting a managed version!).
About deprecation: the gold standard is what AWS is doing with SimpleDB: essentially, never.
The thing here is that if you run hundreds of services in production - many of which work smoothly and you don't need to touch often, you will find that Google's habit of forcing you to change how to use their tooling will generate a huge burden...
They discourage you from using it and make it clear that for every use case some other tool at AWS would be best, and have been doing so for several years now... They wont even list it anymore under https://aws.amazon.com/products/databases/ ..
Still, they support it ( https://aws.amazon.com/simpledb/ ) because there are customers with legacy systems that depend upon this service.
I thought the new title better but I did not want to change the original (because I had already shared the link with friends), so I just changed when submitting. Should've gone with the original...
git-annex. I love this tool - it allows you to have a single virtual gigantic git repository with your entire life inside it. I basically dump everything there in folders and thanks to git-annex it is still manageable.
While I personally never used Node-Red to build anything, I am now a fan of this technology for a simple reason: I saw non-developers happily creating & deploying working and reasonable-quality solutions with it (more than I can say about several tools to supposedly allow non-developers to build working software).
When someone in the business team mentioned they were using this tool to automate a few flows I assumed it would be an abject failure (as happened in so many similar projects I saw before - in some cases in multi-million deployments with huge teams of tools such as PEGA ).
Fast forward a couple of weeks and to my surprise an entire pipeline of needs from the operation where solved/fulfilled with almost no interaction from anyone in the development team. More than that: the end result is understandable.
Cavet emptor, maybe other teams will build horrible piles of crap with it, etc, etc but overall I am still impressed.
