One of my New Year's Resolutions for 2024 was to start a technical blog. Since it's already the last day of January and I've yet to write anything, I felt obliged to kick things off with an introductory post describing what I'm intending to write about as well as some guiding principles that I have in mind.
If any of this sounds interesting to you, please bookmark my blog or add my feed to your RSS reader to keep up to date!
Ideas
In a few weeks, I'll be beginning a new job working on a software stack for a chip designed to accelerate cryptographic workloads (in particular, ZKP and FHE). This is another step in a journey that I've been on since 2019 to become a compilers specialist.
Naturally, I'm planning to document some of the skills that I have to learn on the job. Aside from general compiler knowledge, this will involve diving deeper into cryptography and mathematics.
I'd also like to write some more industry focused content about what compiler jobs are available, how someone might go about getting one of these jobs and perhaps talk a bit about my own experience attempting to make this transition from a generalist systems programmer to a compilers specialist. Given how niche these jobs are, there understandably isn't a great deal written on this topic so it can feel daunting to figure this all out yourself.
More generally, I love to learn how things work under the hood and I suspect that this is a large part of why I'm drawn to low-level programming to begin with. Apart from compilers and runtimes, there are a lot of different types of software that I'd like to understand on a deeper level: debuggers, linkers, compression algorithms, fuzzers, etc. I'd like to be able to describe what makes them tick and how someone would go about building one themselves, ideally accompanied by a GitHub repo with working code.
Principles
When it comes to learning how to build computer programs, I believe that the most important thing is to be prolific. As I was starting out in the industry, I wasted a lot of time bike-shedding on personal projects and trying to figure out the optimal way to design a given piece of code. The reality is that the time I spent didn't improve the code much as I simply didn't know how to design software and that, even with unlimited time, I probably wouldn't have arrived at a good solution. I'm now of the opinion that it's more important to just churn it out, get as much experience as possible and observe firsthand what works well and what doesn't.
I'm trying to apply this philosophy to writing as well. That is, prioritise writing frequently over obsessing about the form, and be at peace with the fact that my writing won't be great at first. My hope is that by writing consistently, producing quality writing will start to feel normal and become part of my modus operandi.
Another principle that I want to stick to is to write in an approachable way that is understandable by the working programmer. One of the difficulties I had learning about compilers was that most learning materials are couched in academic language. I'd like to write in a common sense way that makes these topics feel more friendly and do my part to perhaps dispel some of the mystique around compilers and programming languages.