This article is actually a great example of how to logically approach a problem, decompose it into its components and address each one in turn. In this case the author is applying the process to architectural decisions but the process is just as applicable to debugging and to root cause analysis of system/network problems.

And as usual, when you follow the rigorous process without jumping to conclusions, you can come up with better or easier to implement solutions. In this case, the issue says nothing about Erlang or Python but it says a lot about the choice of serialization methods for a network protocol and the need to choose an appropriate library that meets the use case, i.e. how fast do YOU need it to be. Some applications do not need fast, they need simple. But for the application being discussed, network performance was very important and they made mistakes by not paying attention to that. And as the author points out, the solution that they chose might have made things better, but was less than optimal. There were faster libraries that they could have used, and of course, they might have done even better with a binary protocol.

I was going to get on your case about how referring to the author of the original post as "the intern" constantly seemed dismissive, but I actually can't find byline on the original post. That's crazy. There should absolutely be a byline, especially since it's written in the first person.