munchbunny

My experience has been that paradigms and tools can move fast and are relatively straightforward to pick up. Deep understanding of the underlying problem domain and the systems underneath the abstractions is harder to pick up, but the concepts move more slowly.

I just ask up front whether we can accomplish the same thing without a meeting, and if we can, I just say no to the meeting. If I'm actually necessary, then it'll get done one way or another without the meeting. If I'm not, then it's most likely not my battle to fight. (Substitute "We" for "I" if I'm the manager or a mentor or tech lead or something.)

Yes, it wasn’t my intent to contradict your overall point, just to correct your logic.

My argument was that if the statement "if the light is on it was turned on by me" is true (i.e. the me turning on is a necessary condition) then it follows that if the light is off, I have not turned it on.

I disagree with you here. The counterfactual, or at least the logic theorem, for the statement [light is on] => [I turned the light on] (me turning it on is necessary for it to be on) is [I did not turn the light on] => [the light is not on]

That’s sound, though it’s not a particularly insightful leap of logic.

If you translate this to the author’s point, they’re basically saying that !A => !B doesn’t tell you that A => B. And that’s correct as far as Boolean logic goes. I am unclear on whether we disagree on that point.

To be pedantic, it’s not quite that either. The logic theorem states if A => B then !B => !A. The => means that A is sufficient for B, because “false => true” evaluates to “true” but “true => false” evaluates to “false”. If it were “necessary”, those statements would evaluate the opposite way.

This means that if me turning on the lights is sufficient for the light being on, then the light being off is sufficient to deduce that I did not turn it on.

While I get your point and have been in a similar position myself as the interviewer, the longer I've been working the more I think "creative" is just as much of an overloaded and under-defined term as "smart". These days I just look for the ability to think through complex things methodically, and the creative spark will show itself later, and in place of innate creativity, the ability to churn through lots of ideas when it's needed is a serviceable substitute.

And if by "creative" the interviewers (not necessarily you) mean the ability to come up with novel but compelling ideas, that's something that happens on timescales longer than an interview and certainly not under interview pressure. The people I know who are best at generating novel, compelling ideas do it on the timescales of weeks to months.

A common practice is to exclude both the whole repo and the compiler from Defender.

While that's true, you still have to execute. And when you see mediocre execution, that's still someone who put in the work.

In the context of games, which are more like creative works fighting for mindshare, an idea is analogous to a business opportunity, which is to say that the idea/opportunity will likely look different once it's actually executed on, and that journey is the valuable part even if it fails.

That's not to discredit someone who is good at identifying opportunities. That's a wonderful skill. But I think the author's take which I agree with is that someone who tries to execute, even with a flawed idea, makes more progress than someone who has an idea/strategy/proposal.

Also I think it's important to point out that this blog post is in the context of (board)game design. Everyone has an idea and the vast majority are under-baked, and the process of designing it and playtesting it is how you calibrate on what other people actually like or find fun. I think that's analogous to, say, tech startups, but game ideas are even cheaper than startup ideas.

It's an important technicality that matters when you are doing performance tuning of code on modern CPU's. Big-O is asymptotic but omits the constant multiplier, so if you're comparing, for example, deletion from a naive binary search tree vs. an unsorted array, it's not necessarily obvious that a tree search on a naive pointer based tree (O(log n)) is faster than a find, swap, and delete (O(n)) until n is sufficiently large.

Another example is iterating through the pixels of a very large bitmap on the order of 10m+ pixels. While iterating through all pixels should be linear to the number of pixels (O(width * height)), assuming it's a row-oriented bitmap, which most are, scanning row by row can be substantially faster than scanning column by column because of caching behaviors.

Point being, big-O and actual performance are not always the same thing because the constant factor can sometimes dominate depending on what you're trying to do.

There were a few sets of common numbers, formulas, and mental calculation tricks that were useful to just always have in the back of your head. Perfect squares and cubes under 1000, powers of 2 and 3, prime numbers below 100, interior angles of regular polygons up to 10 sides, binomial coefficients, Pythagorean triples, factorials up to 9!, common roots out to 3-4 decimal places, and a few others that I've no longer needed for almost 20 years at this point.

The discrepancy is that a 75% reduction in users opting into Facebook tracking is leading to only a 30% reduction in iOS share on the highest ROI ad campaigns. 30% is big but not 75% big.

Another possible explanation is that opting out of tracking in iOS doesn't make you invisible. It just makes it hard for Facebook to correlate your off-app/non-Facebook.com web activity, but there are ways around that. So what 30% means hinges a lot on how the 1st touch -> 2nd touch leap is done, and the data for that leap doesn't always come from Facebook.

That's half as many pixels as the 1080p screens that people in 2014 were playing on. Keeping "rendering quality" fixed, pixels and flops aren't necessarily linearly correlated, but half the pixels does mean approximately half the flops to hit the same quality targets, ignoring the new upscaling tech that will almost certainly be used to close the gap. So 1.6 TFlops today vs. approximately 2.5-equivalent 2014 TFlops is probably not that dramatic of a gap.

And running on a battery. That's actually really damn impressive.

At first I aimed for 1 hour of exercise a day. That failed within a week. So then I aimed for 10 minutes a day, which barely felt like exercise, but it got me to the starting line consistently! The trick for me was treating anything past 10 minutes as beating expectations, rather than treating anything under 1 hour as falling short. In practice it means I'm able to get about 20 minutes per day consistently, which is still much better than 1 hour never.

The key for me was making it so I could consistently feel good about a reasonable goal instead of constantly feeling like I was falling short of my own expectations.

Now if only I could apply that to flossing.

Personal example: growing up I practiced the piano for about a decade, 30 minutes at a time, usually 4-ish days each week. I got more disciplined about it as I got older. After 10 years, I went from not being able to play at all to being able to play genuinely impressive stuff. I'm not especially talented, but the consistent application of 30 minutes at a time really did add up to something wonderful.

No survivorship bias needed here. Anyone with access to a keyboard or piano could have done the same thing. Yes, you would've needed to want to learn to play at least a little, and yes, you would've needed to practice at least a little intentionally, but given those things, just showing up consistently over a long period of time can do wonders.

I still occasionally write C++ when I need to, but it's been a long time since I actually enjoyed doing it.

Assuming you’re not a help vampire (I’ve worked with junior engineers like that, and it’s frustrating because they eat up time unnecessarily), then to the extent that you can, I would recommend finding a new team that doesn’t do that. It’s toxic to your growth and career development. Junior engineers might be junior, but “junior” is not the same as “incompetent”, and teams that don’t appreciate the difference are probably not good places to spend your early career.

I do agree though that regardless of your level or the level of the person you’re talking to, you should be respectful, humble, and generous.

But the junior/senior labels definitely exist on a spectrum. I have definitely moved from a more junior place on it towards a more senior place on it over time, even if exactly where I stand on it is for my colleagues to judge.

I think programming as a discipline is chock full of examples of attribution error. When I think back to the less experienced version of myself, or even the current version of myself on a bad day/intellectually lazy moment, or just reading programming forums for more than a few minutes, I can easily come up with examples.

And I can find plenty of examples where I commit this exact error: many, many seemingly stupid technical decisions that can be explained by the context in which they were made, and more importantly, if I were in the exact situation that spawned the decision, it's not clear that I would have chosen differently either. It's only with the benefit of hindsight that I can disagree with the decision, and the really hard, important, career-spanning question is "how would I have arrived at the right decision in the same context?"

The only remotely good answer I've found to that question is reading extensively, especially outside of my comfort zone, which of course I don't do enough of.

I don't think you have to answer the ethical question to address the level of readiness that Copilot or self-driving cars are at. It definitely raises the question, but you don't have to answer it to talk about suitability for use cases.

As you say, it might address the requirements of some specific people. My argument is that Copilot is not good enough yet for the bulk of imagined use cases, whether or not you call that MVP, and I think the post makes a good argument about why.

I think the issue is that the MVP from a customer perspective is, effectively, being able to take a nap in the driver's seat. From a research perspective there are obviously intermediate milestones, but that doesn't make it fit for what people would want to use it for. Same goes for Copilot.

I think it's uncontroversial to say that RSA in practice is a fraught proposition. There are a lot of foot-guns that even the mainstream libraries don't protect you from, so just using RSA means you need to spend a lot of time making sure you're not using it the wrong way, and "how to use it right" isn't elegantly contained in a Stack Overflow answer anywhere. And because RSA comes with so many knobs to turn, it ends up being an extensive analysis task for the poor developer whose job is to write the code. I've been that developer.

However, if the choice is between (1) using RSA, with caveats, because the tech stack is already mostly RSA, and (2) updating the whole tech stack to ECC based algorithms, we are not yet at the point where option #2 is always the right answer.

In general NTFS doesn’t do well with lots of small files because opening files is expensive compared to ext4 (dramatic oversimplification). This shows up in random places where very little actual file reading/writing is happening for each file, like yarn, docker, installing video games, etc.