Here's a nice little reminder from our good friend Dhruv that writing code for blockchains is an extremely hostile experience, as there are many moving factors to take into consideration as one constructs the software. The stakes are automatically raised considerably when you attempt to code on a blockchain for many reasons, as you can see above.

Depending on what decisions the team behind your blockchain of choice made when designing said blockchain, there's a possibility that you're writing code in a scripting language that is relatively new to the scene and woefully untested. If this weren't daunting enough, once merged into the main branch, your code is stuck in the wild under the watchful gaze of hackers looking to exploit any vulnerabilities that you may have overlooked and there's little much you can do to fix that mistake without the consensus of the whole network. To make matters worse, an engineer must have the economic costs of her code in mind to make sure the execution of her script isn't too expensive as to dissuade people from running the code in the first place.

And we're not even done yet. All of these minute details are imperative because you are building on a living network that cannot be stopped at any time, and this network just may happen to secure tens of billions of dollars. A lot of which may be vulnerable if certain exploits somehow make it into production. Talk about a stressful building environment. This is why to me, a tech-ignorant pleb, it is extremely important to keep the attack surface of the blockchain you favor as small as possible. That is why I favor Bitcoin in the long-term, it is focused on a very narrow - yet extremely important - use case and the people working to build out the protocol are laser-focused on decreasing the attack surface.

Oh, they scared

Presented without comment.

Final thought...

There's no swifter kick in the dick than the sound of a hacksaw waking you up an hour before your alarm goes off.