2,531 karma · joined September 7, 2014
Not saying that these are impossible, but at some point you either end up reinventing dependency injection, or you end up with all the problems that cause people to invent dependency injection.
Turns out I kept bumping the Bluetooth mouse which kept waking it up, and it would stay awake for a while, even with the screen closed. Disabling the permission for Bluetooth devices to wake it fixed it, but I had a couple of Mondays where I couldn't do anything for a half hour while the machine charged up enough to boot.
I mean, I can't go to the opera _right now_, but soon enough I can.
Happily, it is a simple enough update (and frequently these changes are automated by whomever is actually changing the library). But when this is something that needs extensive reworking, the project might get turned down instead.
One thing worth noting here is that google pretty famously has a monorepo and single-version policy. Meaning: while you may be right about the subteams/orgchart meta-issue, it's not actually shipping multiple versions of the same subcomponent. There's just one version.
This is not necessarily a _bad_ thing, but in this world it is impossible to be apolitical. The only thing you can be is okay with the status quo.
However, given the system under analysis, because corporations have a history of making it very difficult for labor to be paid a fair and living wage, it falls to the government to use the tools at its disposal to ensure (as much as possible) that employees are paid fairly and have an opportunity to spend that pay on health insurance, because corporations won't be volunteering to do that, especially if they're already burning in excess of a billion dollars a year.
When I interview people, I give pretty straightforward questions. My goal is not to run some algorithm guessing game. If I'm interviewing for a senior FE position, I make sure they know enough about async patterns in JavaScript that I feel confident that they could build an event handler without dropping promises on the floor.
A back end position? Can they use (not implement, just use) a hashmap efficiently and do they think about boundary conditions in input sets (you'd be surprised how many people ignore punctuation when breaking sentences into words - they just do a split(' ') and call it a day.
This is really basic stuff. I'm always able to (a) filter out people who just need more time learning to code (or are too nervous to perform well, which is still a problem with even these whiteboard activities) and (b) prompt a discussion about engineering practices.
My criterion is simple: do I think I could see this person submitting code to my project without me needing to constantly fix what they write? It isn't about memorizing algos or anything.
Aaalso: I didn't study leetcode, and managed to get my job just fine. I know there's a reputation of the process being just algos, and I'm sure a lot of the interviews are. But not all of them, even at the FAANG.
Meaningful apologies can be easily found via the search engine of your choice, "How to apologize" brings up lots of hits. The thing they all have in common though is an acknowledgement (in one form or another) that the person apologizing was legitimately in the wrong, and that they will endeavor to not do that again.
It's that last bit that is important. It's not sufficient for a company to apologize for dumping oil in the ocean or a person apologize for using a racist term. A real apology acknowledges harm caused, and shows how the entity apologizing will rectify past harm and prevent future harm.
This is why, in my opinion, at least, so few apologies legitimately improve anyone's standing. It's not that "cancel culture needs heads", it's just that people expect to say, "I'm sowwy", rub their toes in the dirt, and be let off the hook without doing anything to really undo the harm caused. People rarely even acknowledge the harm they cause, let alone do anything about it, in these so-called apologies.
So no: people who demand apologies don't just reject them after they're given. It's just that most of the time, the apology is meaningless.
Furthermore, I can also, when I'm building out the first-form HTML implementation of the mock, right-click and copy-as-svg the whole component, which makes for a nice stand in while I work on the rest of the code. It is great.
I mean, the data is still accessible, it's just not easy to get it willy-nilly without setting off alarms.
It isn't only prop 13 that is to blame for the bay areas particular housing crisis, but encouraging towns to not approve residential starts cannot help.
It doesn't make sense to pay people low wages to the point where they need governmental assistance in the form of food stamps and BMR housing, and then pass on the savings to private companies who do their best to avoid paying the taxes that fund those programs. It ends up being other, traditionally employed FTEs who subsidize this business model via their own tax bills.
I stopped akido due to a knee injury, but yikes were my wrists strong for a while.
I'm sure there's ways we can improve our canonical agile-ness, but it's not lip service. We set quarterly goals sure, but they can change if situations change and the goals themselves are usually data-driven (based on prior quarters a/b testing and other research done by our UX team). We also have strong product and project managers, who own a lot of the scrum meta-work.
So, I guess #notallgooglers (which for context is an ironic, kind of self deprecating response here). There's tens of thousands of engineers at G. Some teams are agile, some aren't.
From 2014 though.