You're looking at human nature. We evolved to conserve energy, to take the berries that are growing right here rather than go foraging for something else with less certain outcomes. Even better, someone else collects the berries for you.
There are some exceptional people, who have the drive and curiosity to see what else is out there, but that's not the average.
They'll frame it as not wanting to waste anybody's time by submitting you as a candidate if you're already mid-flight on other positions, but they can still figure that out without having specifics on the actual company, role, salary, etc.
They're banking on you offering it because saying no would rule out any mysterious prospects they have to offer, but really they're looking for new leads and if it comes from a candidate then it's warmer. Just have to be polite when you give them vague info and say you're not able to share more than that.
I had a really weird power-trip interview once, and it was the CEO who was joined by a contractor who was ostensibly the technical lead for the project. There was nobody in engineering who worked full-time on the job, everybody was contracted. I was also going in as a contractor so I was aware that the interview would be a bit lighter on process as a result.
The questioning very quickly veered away from technical stuff and into stuff like, "where do you stand spiritually?" and other questions probing into whatever bizarre cosmic insights I could pull out of my ass at the time. He was the really intense kind of boss who wants to make sure you know of it with the hard back/shoulder slaps and micromanagement, and I could see his office from the boardroom which basically had an array of monitors all wired up to CCTV so he could watch (and hear) people from the comfort of his desk.
If any of that wasn't a red flag, getting hired literally 5 minutes after leaving the office was probably the biggest. I lasted about 6 months and even trying to leave was an ordeal.
> I lasted about 6 months and even trying to leave was an ordeal.
Like finding your next gig or just not showing up ever again? Because I've worked at a place where someone came in, went to lunch, and they never saw them ever again.
In general as companies decided to treat people like fungible cogs while selling "we're are family" story, it should be expected people will start treating companies like the faceless and soulless entities they really are. When people are laid off and escorted out not even allowed to say goodbye to their coworkers, employees should be just be walking out and doing exactly the same thing to those companies.
I got a gig as a contractor for a well known company. They were hiring and he told his recruiter to get him in. After several conversations trying to tell him not to come in and telling him what a clown show it was, he still managed to get hired.
Same thing. Came in, continually had to ask me how to do stuff, and I kept telling him, "See man, I told you this place is a clown show!". He did the same thing. Left his laptop, "Going to lunch, be back in an hour."
The most shocking part of this story is the part where you took the job. Not trying to throw shade, just the truth! What on earth was going on that made this your best option?
It kind of is though. Someone else will say "why are you sourcing results from an Israeli company?" and another will say "why are you sourcing results from a Chinese company?" and another one yet will say "why are you sourcing results from the US?".
Why are the ethics of working with Yandex or Baidu any better or worse than the ethics of working with Google or Microsoft? Except that they're not western.
The logical answer is that a person like this wants a very strong firewall, so ethically impure bits don't cross into their LAN.
What are the challenges of doing that when so much of the internet has turned itself into SEO slop to fit Google's algorithms?
I imagine there is still a whole load of stuff out there on the internet that Google would never surface because it doesn't have enough adsense or whatever. Are you finding that?
That's what SlopStop is for :) developing methodologies that scale for detecting slop.
I mean it sounds like that already has a lot of overlap with our Small Web indexing efforts, so that part of our indexing efforts could be an extension of that. A lot if this is still in development though so I can't speak on specifics just yet.
Go is really easy to read and write, even if Go's philosophy means that some of that feels clunky because it's less featureful than other languages. It makes up for it with a comprehensive stlib that makes it trivial to build services with few to no third party dependencies.
I don't think the value prop has changed at all there. One day the AI gravy train will stop and people who used AI to punch above their weight will no longer be able to debug the stuff they built unless they put in the hard work of learning the language.
Nothing to worry about with Go in that respect because of how much it's been designed to be simple. Even the annoying err/nil checks you need to do all the time are in service of that simplicity. It gets old fast but it leaves nothing to the imagination.
We switched to 'software engineer' to encapsulate that, I think. You can receive requirements and churn out code or you can go up a level and think about the solution. Go another level up and think about the problem. Another level and it's the context of the problem. Further than that and it's the priority of it. And even higher up is how it fits in the product roadmap and the architectural decisions.
At some point you stop developing and start weighing up the requirement against your understanding of the system and the environment it works in.
'yes, you should' needs to be reconciled with 'it's f*g expensive' and 'risk is low'.
nowadays, 'risk is low' isn't true anymore and it's actually cheaper to have a robot spit out a reimplementation of the 5.4% of what you need out of your dependencies instead of auditing the 100%.
People have for years. The real question is do people enjoy not putting any thought into their super convenient JavaScript stack too much to actually do anything about it. Delaying updating to new packages assuming the vulnerability will be discovered in two days or whatever is putting a knee brace on a leg that needs to be amputated. Sooner or later there will be a vulnerability good enough to not be caught in a couple days, or a zero-day damaging enough that not updating immediately is a huge risk. Assuming they won’t be in anything critical enough to disastrously compromise your stack is wishful thinking at its finest.
The part that always gets me is I tend to only install a few packages like React and maybe some kind of data access layer. But you let that recurse down a few levels and suddenly you've installed a thousand packages, some of them hopelessly obsolete, some of them for patently stupid things that are 1 line of code, etc, etc. I.E. you can't choose to be thoughtful if the main entry points into the language are all built on a pile of garbage.
Oh yeah, for sure. The problem (mostly) isn’t people installing packages willy-nilly: it’s that the attack surface is fractal, which is just plain nuts.
Now that npm supports --before, yarn supports npmMinimumAge, and pnpm supports minimumReleaseAge, it's quite possible to stay safe and avoid acciasional bleeding-edge upgrades. Stay a couple months into the past, give testers time to look at newer releases and vet their safety (or report an exploit attempt).
npm's immaturity is arguably demonstrated by the fact it is always catching up.
Please correct me if I'm wrong but signed packages are still impractical in NPM which is why supply chain attacks still work by editing existing versions or pushing new point releases without a signature.
Or if you put all of the credentials in GitHub actions which is even more trivially exploitable through the actions marketplace because it is just git with a thin proxy, you have an even wider attack vector
In principle I agree, but chrome has an auto-update setup and using that mechanism to download several GBs of data that is not critical to the app itself is cause for question.
Chrome is not entitled to my disk space just because I installed it and Microsoft has been excoriated for the exact same behaviour with AI.
>Chrome is not entitled to my disk space just because I installed it
When you install any program it becomes entitled to your disk space, by the definition of installation. If you don’t like the program, you can just uninstall it and it’ll no longer take up your disk space.
It's entitled to what is a reasonable usage of disk space, which you generally know by the size of the installer. Some install mechanisms bypass that because they give you a minimal installer that then downloads the full package. It's not entitled to unlimited usage.
Using that same mechanism to pull in several GBs worth of extra data without any warning is sketchy. If this happened and did not respect any settings for running on a metered network then it is even worse.
Other applications where this entitlement is better understood usually have a mechanism to purge the space it uses. e.g. Docker will consume whatever space you give it but you have commands to purge that space or to limited how much it will consume if it goes through a VM.
I really don't know why anyone would try to defend a tech company on what is a table-stakes expectation for being a good actor in the ecosystem. It's really lowing the bar for the supplier's sake instead of keeping the bar high for the consumer.
As a counter point, Call of Duty (the game) was mocked for requiring a good 200+GB of disk space and the conspiracy was they did that to push other games out of your storage. The market response there is easy: don't buy COD and don't install it.
I don't think it's quite the same for a browser that abuses network effects to stay useful. In which case Chrome is to Google what IE6 was to MS. A separate topic but we know that not all browsers are considered equal on the web.
It was disappointing hearing someone tank their own prospect of career growth like that.
reply