Got a music degree, decided the career wasn't for me, went to a programming incubator, really struggled with interviewing for a while, got a job at a startup, got a job at FAANG, here I am a decade after the career switch
Thanks, I enjoyed this and it rings true. This abstract concept of "space" getting filled up thoughtlessly, and that "space" being created by unnecessarily breaking things up into smaller parts that don't really need to be separate, makes a lot of sense and I think I've seen this happen.
The article stops short of proposing a clear plan for how to handle the opposite problem, though: Entrenched monoliths. Once a class (or other abstraction) has grown for long enough (e.g. perhaps someone has read this article and is trying to avoid unnecessary complexity of code structure), it can become very difficult to break it up.
Try not to worry about what others think of you, and definitely don't think about IQ. Judgment is so much more important than speed. Why are you concerned with speedy thinking?
First example seems odd? The author acknowledges that the two proposed alternatives (printing "<function exit>" or actually exiting) aren't great. The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier. This is especially notable given that in the next example, the author's complaint is about a command _not_ providing special guidance about the thing the user is probably trying to do.
Yep this happened to me yesterday. In a taxi, the driver was following Google Maps, which showed a 22 min ETA, with one or two alternatives adding a minute or so. My phone was open and showed the same options. He felt certain that he knew a better route—via a highway, not a back road—and when he took that first rogue turn, Google Maps adjusted and the ETA instantly dropped to 14 min.
Beautiful Country, by Qian Julie Wang. Beautifully written memoir about immigrating to NYC as a child in the 90s. Poignant, sweet, honest, easy to read, fun, not too too emotionally heavy, but also full of lessons about trauma.
Sounds like the thing about "ad blocker sabotage" is about replacing the Web Request API with something called declarativeNetRequest. I've been sifting through documentation but have had trouble seeing why this is any kind of a downgrade for ad blockers. Can someone explain?
Reading https://github.com/total-typescript/ts-reset/blob/main/src/e..., I'm more confused than before. The generic NonFalsy<T>[] looks to me like it should evaluate to never[] if the entire array is false, and to T[] (the original array type, not narrowed) otherwise. But I can see that the test case demonstrates that it works. What am I missing?
is interesting because it makes use of the fact that the types of individual array members are known at compile time. I can think of some times when I have dealt with arrays that are defined at compile time, but not where I've needed to call .filter on such an array. Is there a common use case here?