They did not know it was impossible so they did it.
- Mark Twain
This first half of the year has been productive and inspirational.
To start with, enough time has been invested into this blog to make it into a platform I am motivated to progressively add to as I learn and discover new software development-related tidbits in my life! I wrapped up the series on my NixOS setup and tried my best to explain multivariate interpolation in a little WebAssembly demo I wrote in Rust.
In February, I made my first sizable1 contribution to open source software! The project I contributed to is Sourcehut. It’s “brutalist” design and Unix-style, modular components make it appealing to me. More importantly, it is FLOSS. I recently learned more about what software “freedom” really meant and why it is important. In particular, I came to the understanding that contributing to open source software is worthwhile because you’re doing it for yourself, and if you’re fortunate, your changes also end-up benefiting the whole community.2 Sourcehut is being developed/spearheaded by Drew DeVault who works on a number of projects but is perhaps best known for his work on sway and aerc. Some discussion has been made on the next bit of work I hope to contribute, although I have yet to find time outside of work to make any significant progress on it.
Without ever having had a formal education in computer science, I had always felt lacking in terms of algorithmic thinking and analysis. This March I started taking a self-paced course, Algorithms: Design and Analysis by Tim Roughgarden, in order to fill in the gaps. It has been admittedly quite demanding to juggle alongside work, and despite the exercises being impractical for production, the principles/concepts that I picked-up have already proven to be beneficial in my day-to-day work. I’m happy to say that I finished the course at the end of May (which has finally opened-up some time for me to catch up on my blog)!
That summarizes the first half of the year, which brings me to the quotation I began this post with. A recurring theme of the past six months has been, finding the courage to challenge existing methodologies, whilst motivating inventiveness using foundational truths.
Shortly after joining MPC to write software, whenever I learned that something in my work was considered “bad practice”, I made it my mission to “learn” from my mistake and avoid said something like the plague. Over time I had accumulated a hoard of so many different rules that I was writing “effective enterprise programs”, but had lost the ability to creatively and elegantly solve problems, instead, I was chasing best practices and playbooks. As soon as I realized this, I left my job to seek constructive criticism from other people, people I had never worked with, who had the capacity to question the choices made in my code, and force me to validate and re-evaluate the rules I had built-up.
Risk averseness comes from experience, and that experience is essential to enable one to see multiple, complex systems as a bigger picture, hence why seniority is valued in the workplace. Yet, sometimes we need to review these experiences after they have settled, to see if they are still justified. Finding the balance between hardened experience and progression is often difficult, and I strongly believe that taking our time to find that sweet spot is necessary in order to maintain and produce healthy software.
Further to my point, it has come to my attention, that the software community is “progressing” towards an increasingly self-destructive and unsustainable future. With software being an important extension to our regular human limits, this is pretty concerning! I will save myself some words and let a couple of great lectures from Jonathan Blow and Casey Muratori do the talking.
It is from these talks that I feel compelled to share my personal goals and aspirations for: the short term (the next six months), and the long-term foreseeable future. There is also something about making your goals public that 1) make them more official, and 2) puts a healthy amount of accountability and expectation on yourself.
As a broad, overarching goal, I would like to revisit some of the core directions that the computer graphics industry appears to be heading. What are the implications of studios adopting standardized scene description by way of USD? How much of an artist’s workflow is dictated purely (and naively) by the programs they use? Some of which encompass a number of worryingly dated practices that haven’t ever been critically reviewed, most likely only seen as, “how things have to be done.”
I would like to begin my research by taking a look at rendering. I am hoping that my little-to-no experience with rendering will bring novel ideas that prompt more members of the industry to reconsider the current state and future of computer graphics software.
On that line, I have only a couple of big points on my agenda for the next six months. The first is to consolidate my understanding of Linear Algebra by taking the course, Linear Algebra: Foundations to Frontiers, provided by edX. The second is to begin to write a physically based renderer in C.3 The project will be entirely open source, you can follow my progress here.
All-in-all, this is clearly a long undertaking that will require effort and patience, but as I mentioned earlier, taking one’s time is an essential ingredient in making meaningful change. J.R.R. Tolkien, for example, spent time in the order of decades working on the universe in which he would unravel many timeless characters and wonderful stories.
I would love to hear any thoughts and opinions by email. Thanks for reading and happy hacking!
That is, not counting small configuration/documentation patches. Albeit this patch in partciular wasn’t large, but it took me a week to put together! ↩
Why in C? This seems directly counter to my previous points about challenging existing assumptions! In short, C has and still is withstanding the test of time. Most of the software that I use on a daily basis reliably, is written in C. It is a stable language that provides nearly everything that other languages do, but did so many years before they came to be. I would use Go, but garbage collection is a dealbreaker for performance. C++ has become a monster of cruft, and Rust tries to solve many of those problems whilst hiding too many of the interesting-yet-gory details. Ultimately, C is arguably more simple and powerful than any of the existing options. ↩