Then in the draw phase you could choose which deck to draw from, eliminating the mana flood/drought possibility that ruins games.

Maybe some additional rules to limit how many lands you're allowed to draw in the initial draw to one or two, I dunno.

But now Big Bird is making a whole lot more sense.

Or produce the necessary items on your own. Growing things isn't difficult.

We experience reality filtered through our senses and our own concept of "self," which is an incredibly limited view of the world. Imagine being able to see/experience a less filtered version of reality, if only for a short period of time.

Or imagine expanding the frequencies of visible light you can see. That alone could certainly be a catalyst to change your perspective on many things.

It's not so much "losing control" as it is "losing unconscious bias." Loss of control is not the goal.

It's also one of those things that you have to experience to understand, and even then, sober you won't completely understand.

But done right, these experiences can be incredibly important to people. If it's not for you, fine, but it's funny how many people with zero experience with these substances think there can't be anything worthwhile there.

There is an appropriate amount of architecture and design that should go into systems. One aspect of that is how much effort you put into scalable design. Building and maintaining scalable systems isn't free, so the "right amount" is pretty much somewhere between "none" and "we are AWS."

Knowing when adding complexity is worth doing takes experience, humility, and maturity, the exact qualities that are sorely lacking in many egomaniac software developers.

It's why we get ridiculous fads and pendulum swings where people get fed up with bad design and then go do the opposite thing, having learned nothing.

Approve the PR when there's a bug/task filed to fix the thing later and then prioritize that work as necessary.

Just as bad as never fixing things later is never releasing anything until it's perfect, which it never is.

Opt out? You get the most annoying ones.

Now imagine if it were possible to instantly and cheaply travel to Paris this way. Many people would likely be just fine with doing this.

Now imagine that one day, the transporter doesn't destroy the original you and now two copies of you exist. From that moment on, the individual experiences diverge but each copy believes it's the original.

If ten days after that a technician came and said "ok, time to disintegrate you, don't worry, your copy in Paris is A-OK" I think that most people wouldn't agree to be disintegrated just because another mostly identical consciousness is alive.

And yet, if it were to happen flawlessly and instantaneously, likely that same existential fear doesn't exist. Most people think the star trek transporter is pretty cool.

But why? We have to realize that our consciousness is really an evolutionary trick that's expedient for our continued survival. The idea that the survival of my own ego and continuous conscious experience is pretty much the basest mechanism I have that makes me value staying alive.

But there's a paradox in the case of my exact copy. Logically, I shouldn't care of the star trek transporter works instantaneously or not. Let's say that it makes a copy that exists for twenty minutes before disintegrating me, but I have no way of knowing that and instead just sit in a room bored for twenty minutes until disintegration. Functionally that's a nearly identical experience to instant transport, but also seems a lot more like the broken transporter scenario.

But let's say this is the future of travel and everyone accepts the fact that my continued conscious experience is what's really important, so I'm willing to be disintegrated painlessly as long as a copy of me exists somewhere else in the universe.

That's not too big a leap to make, but it seems strange, right? Why am I not then just fine being disintegrated as long as any consciousness continues to exist?

My answer to that question is that it's an evolutionary advantage to want to live, therefore we want to live. A bit of circular reasoning. It's also our species' biggest unquestioned assumption too - that consciousness and self-awareness is better than the alternative. But "better" might just be "important to the survival of the human species."

I think the article touches on that.

If you're doing this at such a scale that encoding speed matters (like if you're Instagram) the major concern would likely be cost, which you're going to save in bandwidth every time an image is viewed.

More of a "whoops, woah cool" than a "let there be light"

Very much unlike of the Christian conception of God.

I'm not describing this well, because I can't describe it well. But I can't imagine anyone experiencing something similar would be a jerk about it. See the universe unfiltered though the mind's perception and it just...is. Timeless and meaningless.

Consciousness and ego create their own meaning.

Have you ever wanted to write a command line executable and gotten hung up on I/o and parameter parsing?

With PowerShell you can write a cmdlet in C# as a PowerShell module and have strongly typed input and output parameters for free. It's a revelation.

As as scripting language, it's fine but for me the killer feature is being able to easily extend it in a non-scripting language.

Before Challenger, space flight seemed to be on a constantly improving trend. And likely it is, just on a much longer timeline than we supposed as kids.

Tech is similar - the advancements in the 80s-2000s in the computer industry felt much more revolutionary. I think that had a much larger impact than anything that's happened since.

The next revolution will likely be elsewhere like medicine.

Them: hi

Me: Hello, how can I help you?

[Two minute wait]

Them: How are you?

Me: Great, what do you need?

[Ten minutes later]

Them: Do you have a few minutes?

Me: Am I on candid camera or something?

As a manager they create perverse incentives especially if you have a high performing team (which you want to have) that all deserves a promotion but a limited budget. The incentive is to keep that low performer around so you have the budget to promote the others.

It's a systematized way for management to shoot itself in the foot. But for whatever reason we think something must be wrong if we're not giving and getting report cards at the end of the year. Waste of time and counter-productive.

It started out pretty bad, but now it's delicious and my kids get excited to eat it - they think it's the best crust ever.

It's not the recipe at all, either. The technique makes all the difference, at least for the dough.

Also, Windows is an excellent way to learn systems programming because the documentation and tooling is so good and things hardly ever change.

There is a wealth of documentation on MSDN for writing device drivers and such. And great tools for remote debugging so you can set up a VM in hyper-v and step through the code from the host system.

Do make sure if you're analyzing malware you do it in a VM on a machine you don't care about having to wipe, and isolate it from the rest of your network.

If you're halfway intelligent with technical skills you will find something to do for four years, then you'll have better options when you get out.

Probably better than being homeless.

In the case where there are mocks, the unit tests are almost always literally testing "can my programming language call a function and return a result" or "can we store data in a database if the database works?" They are functional tests disguised as unit tests, and are testing only non-production fake functionality.

Write functional code instead. Liberally use the compiler and the type system to make mistakes impossible instead of unit testing.

Unit tests are for when you can't express something in a way where the compiler and type system will save you from errors.

Everything else is a functional or integration test and should be testing the production system, not a mockup of the production system that works differently.

Basically, write Haskell programs in whatever language you're working in. Use unit tests as a backstop for when the type system isn't as good as Haskell's.