Plurrrr

In order to effectively write applications that communicate via sockets, there were some realizations I needed to make that weren't explicitly told to me by any of the documentation I read.

If you have experience writing applications using sockets, all of this information should be obvious to you. It wasn't obvious to me as an absolute beginner, so I'm trying to make it more explicit in the hopes of shortening another beginner's time getting their feet wet with sockets.

Mathematicians are a peculiar people. We live in our own little world, studying esoteric ideas that may or may not have much connection to the real world. One might wonder whether the bulk of what we study is actually useful. It’s true, after all, that we often pursue ideas not because there’s an immediate application, but simply because they’re interesting. By and large, it seems we aren’t overly concerned about immediate real-world application of our results.

Don’t start campaigning to cut math funding just yet, though. Math that doesn’t have applications today may very quickly become extremely important, even becoming integral to our way of life!

Software is written for people to understand; variable names should be chosen accordingly. People need to comb through your code and understand its intent in order to extend or fix it. Too often, variable names waste space and hinder comprehension. Even well-intentioned engineers often choose names that are, at best, only superficially useful. This document is meant to help engineers choose good variable names. It artificially focuses on code reviews because they expose most of the issues with bad variable names. There are, of course, other reasons to choose good variable names (such as improving code maintenance).