Experiments in managing perfectionism

Rust

I've been spending the start of the week learning Rust. I opted for O'Reilly's Programming Rust initially as it closely follows UPenn's CIS198 (problem sets FTW), but has since switched to the Rust book as I'm finding the style a bit more fun.

Content: Innovation tokens

I knew Dan McKinley's Choose Boring Technology post would feature on my content list. I especially love the framing of innovation tokens, and how you have to choose your battles.

https://mcfunley.com/choose-boring-technology

What caught me by surprise re-reading it today is how it feels less clear what's considered as spending those tokens. NodeJS is widely used, and I found out recently Stripe uses MongoDB for core parts of its key-value infrastructure (cue "is your database web scale" jokes).

My experience with the supposedly battle-tested Airflow hasn't been positive. We employed a number of workarounds to get it to play nice for long-running (~8 hours) ML model training on containers. We ended up partly moving to a scheduler built in-house (for model training jobs), before moving wholesale (plus ETLs) to Argo. Sure Argo is built for k8s, but the sense with Airflow was "it shouldn't be this painful"...

It's hard to disagree with the principle, as per the post, that one should always consider cost-benefit trade-offs carefully. That said it does seem a lot simpler in the abstract. Is Rust sufficiently boring?

Python

I've been spending a fair bit of time learning new programming languages recently, and I'm quite happy to have the progression be Python to Go to Rust. When learning something new, your motivation gets a boost when you can do lots of things and do it fast. From this perspective, it's hard to beat an interpreted language like Python.

Python is the main language at my previous role, and this choice makes sense given how key ML models were to the business model. Having the data science and engineering share the same language helped reduce maintenance and tooling overheads, as well as provide better context in handoffs.

The drawbacks were speed and lack of types. For speed, we had bindings to C++ on the hot path - the need for speed in an auction setting is clear. For types, we gradually introduced type comments with mypy. Why types? It's easy to introduce bugs when refactoring a codebase with limited guard rails; types are like tests that you get for free.

Go

I had the chance to learn a bit of Go just before RC, motivated partly because it's the main language for Bradfield's CS Intensive course. I was pleasantly surprised to find a lot of tooling we used for Python comes built-in in Go (brief discussion here). Go also has first class support for concurrency; the language is a popular choice for servers given the need to support multiple clients simultaneously. The syntax was surprisingly easy to pick up coming from Python.

Rust

I wanted to know more about the front end at RC, but curiously got into WebAssembly in the first week. I then found out from Tom how Rust has the best from-scratch support for compiling to WebAssembly. Another reason Rust works better is the smaller runtime - the smallest achievable binary size uncompressed from Go is ~2 MB vs ~2 KB for Rust. I'm not as familiar with the finer details, perhaps a sizeable part of that can be attributed to garbage collection in Go.

In summary, Python for fast prototyping and 'glue code', Go for concurrency and Rust for the low level stuff. Next comes lots and lots of practice.

Content: Disruptive innovation

If you've come across the theory of disruptive innovation, Jill Lepore offers an interesting and persuasive take in the New Yorker.

https://www.newyorker.com/magazine/2014/06/23/the-disruption-machine

Love how there's a reference to HBO's Silicon Valley.

Go

I've been spending the week on reading and writing code. I needed a breather, and made it a touch lighter today with blog posts and Youtube videos.

I found this post by Discord describing how they moved one of their services from Go to Rust. The engineering team discovered latency spikes from garbage collection, how performance issues persisted after tuning, and then decided to make the switch. Jon Gjengset in this video described how in Go, "even though concurrency is very easy, that concurrency is very easy to shoot yourself in the foot with".

Rust

I'm a believer that there's a tool for every trade, and keen to develop the sense where one would choose one tool vs another. I didn't pick this up in my earlier readings, but found out that creating a doubly-linked list in Rust is non-trivial.

Content: Farouk al-Kasim

I re-read my favourite articles before sharing them on here, some really do make me pause to reflect. This is a story of Farouk al-Kasim, who left Iraq months before the Ba'ath party took power and then prevented Norway from squandering its new-found oil wealth (enclosed below).

Content: Tango pour Claude

I remember hearing this and being very, very happy I asked for the name of the piece.

Content: BBoy Cloud

A little random I know, but why not when you have this much style.

Content: Siddharta

Re: self-reflection, I have to include Hermann Hesse's Siddharta. I love how the book highlights the importance of experience. It's tricky choosing just a single quote, but this one ties in well with being at RC to learn (or perhaps, learning through the experience of what works and what doesn't).

Has any samana or any Brahmin ever feared that someone might come and grab him and rob him of his learning and his piety and his profundity? No, for they are his own, and he gives of them only what he wishes to give and to whom he wishes to give. It is the same, exactly the same, with Kamala, and with the joys of love. Red and beautiful are Kamala’s lips, but try to kiss them against Kamala’s will, and you will not get a drop of sweetness from the lips that know how to give so much sweetness! You learn easily, Siddhartha, then learn this too: One can get love by begging, by buying, by receiving it as a gift, by finding it in the street, but one cannot steal it.

On exposure

Every Friday I would look back at the past week, but would be too wiped out to articulate it clearly. This occurrence was especially annoying last week, as it marked a quarter into the batch.

I've covered a number of different areas in the first three weeks. At a coffee chat today I realized the time so far had not reinforced my interest in any particularly, but instead exposed me to a whole new world of things. Suppose I had three choices before, how strongly I feel about each of them hasn't really changed. However I now know there are seven choices.

Rust

I'm very much enjoying Rust. I haven't done it for long so I won't say too much, but it appears the compile times can take a while. That being said, a toy implementation of generating the 10,000th prime number averages at 0.25 seconds for Rust vs 3.88 seconds for Python (code here, inspired by post here).

Over the weekend I discovered RustPython, a Python interpreter in Rust. Since Rust can be compiled to WebAssembly, the interpreter can be made to run in the browser. The FOSDEM 2019 talk can be found here.

Content: Learning at startups

I've always believed in choosing a role that allows you to maximize your learning. In the context of startups, Paul Buchheit says it best.

https://triplebyte.com/blog/interview-with-gmail-creator-and-y-combinator-partner-paul-buchheit

I would suggest thinking about joining a startup as more like going to grad school to learn. Optimize around learning when choosing a job. That’s the best thing. Then if a startup fails, you can always go back to Google and probably get paid a lot more, because now you’re actually a much better engineer than you would have been if you had stayed there like everyone else.