Plurrrr

Would you believe it if I told you that something called "rubber ducking" is actually one of the most insightful debugging techniques ever suggested? When you run into a programming snag you can't figure out, just find a rubber duck and start talking to it about your problems. Sold, right? Me neither.

I actually love rubber duck debugging, but not in the way it's usually explained. Turns out, it's hard for adults to take seriously the idea of talking to a literal rubber duck on their desk. And even if you guessed the duck is not really the point, you'd be surprised by how many engineers miss the point entirely. In this article, I'm going to explain what rubber ducking is, why it does actually work, and provide a step-by-step process for the way I do it that I think can change your debugging chops for good.

In past projects at Qvault we had an application that typically ran with ~2GB in memory at any given time. By simply changing the order of some uint variables we managed to drop the memory usage to less than 1.4GB. The vast majority of this allocated memory is due to an enormous slice of stats structs.

There are lots of techniques to generate Pseudorandom numbers, namely: Blum Blum Shub algorithm, Middle-square method, Lagged Fibonacci generator, etc. Today we dive deep into Rule 30 that uses a controversial science called Cellular Automaton. This method passes many standard tests for randomness and was used in Mathematica for generating random integers.