Francesco Allertsen - Issue #93

I agree with this statement. The company culture is something you don’t really understand, especially if it’s not clearly written. But you can clearly see the difference once you change company, and then “something” is not right, or it’s way better than before, but you can not pinpoint exactly what it is. That’s the company culture.

This article is not new but explains a bit how Stripe works as a company, and there is a lot of very interesting information, and I think many other companies can benefit from copying some of these practices.

This title is the best advice I can give to anyone: If you don’t understand something, simulate/reproduce it.

That’s how I learned most of the things I know. I have studied computer network on the books, but I have started to really understand it when I started reading the content of all the packets running through my network card, and when I wrote my own (minimal) TCP implementation, and when I played with a much larger TCP implementation.

This is just one simple example, but it can be applied to anything. I strongly believe that trying to clone software or digging into how a system work is the only way to really understand something, and this article is a clear example: Do you want to know how a CPU work? Simulate one!

This article describes a bit how the implementation works, if you want to know more you can read the code or implement it your own. Actually, this article added me even more curiosity to start implementing my own CPU :-).

I have always thought that random.org was just a simple website on top of /dev/urandom, but I was wrong.

This is a very fascinating story of how the project started in 1997 with a $10 radio receiver and now grown into a much larger system (there are some pictures included in the article if you are curious).

Generating random numbers is not trivial, and it’s very interesting to read a bit of history behind a project like this that manage to generate randomness over the internet for more than 20 years.

Rewriting a big code base especially when users are already using it is not easy, and that’s what this article is about.

This is a very detailed article about the work of the Slack Python SDK maintainer on how to improve the library with minimum effort and disruption from the customers.

It’s very interesting to see why he made some of the decisions, and what were the problems he faced during the implementation.