• 0 Posts
  • 57 Comments
Joined 2 years ago
cake
Cake day: June 20th, 2023

help-circle




  • I did recently discover you can turn off “Web and App Activity” for your Google account, which seems to disable Google saving most of your data (searches, viewed places, etc), for what that’s worth. It definitely cripples Google maps even more than I think it should, since now I can’t even search for labels I’ve added to Google maps myself.

    I’ve been meaning to try Organic Maps as well, but haven’t even gotten around to installing it yet.













  • … You know not all development is Internet connected right? I’m in embedded, so maybe it’s a bit of a siloed perspective, but most of our programs aren’t exposed to any realistic attack surfaces. Even with IoT stuff, it’s not like you need to harden your motor drivers or sensor drivers. The parts that are exposed to the network or other surfaces do need to be hardened, but I’d say 90+% of the people I’ve worked with have never had to worry about that.

    Caveat on my own example, motor drivers should not allow self damaging behavior, but that’s more of setting API or internal limits as a normal part of software design to protect from mistakes, not attacks.




  • Thinking about it a bit more, I think it’s more like the metrics used to get in front of a human (the automated/hr part) aren’t well matched to the actual goals. We end up interviewing a lot of people who are good on paper according to the first sort, but actual good hires within that aren’t as common as we’d like. But none of the engineers ever know about any of the people who were disqualified due to having an unimpressive resume…

    So in the end, the initial sort does indeed end up wasting time and money, but no one’s gotten around to making a good solution for this yet. The alternative so far is to interview a bunch more people, which is also really expensive anyway.

    Basically, we have no efficient way to find people who are bad on paper but are actually quite skilled.