How to Land Your Dream Job Using Relational Algebra

Photo by Kelly Sikkema on Unsplash

Hello! I'm Felix, a software developer and one of the latest additions to the Klaro team. I'd like to tell you a little story about how I found my way to working with such talented people on such an impressive piece of software as Klaro.

Five years ago, I started my slow ascent into the anti-ORMer mindset, an idea amongst some programmers that the way the world has been interacting with databases over the last couple of decades has been a big, painful, costly mistake. Does this sound like a mundane, boring technicality? Maybe so, but let me point out that database access is at the very foundation of virtually every little app, ticket vending machine, online game, social network, and cat meme generator that together form the fabric of our digital existence. Getting this right is no small matter.

At some point during the course of my frantic reading and note-taking on the topic, I saved a link to a post (Some) ORM haters do get it by one articulate anti-ORMer. That link would turn out to be instrumental in setting me on my future path.

But first, I should explain what is at stake here.

What We Wish it Was Like

One of the trickiest things about programming is when you have a bunch of pieces of code that each work fine on their own but it's hard to put them together. Some times, the parts only work when you connect them in a very particular way. Other times, someone managed to get all the parts to work together years ago and now you need to change some little thing in one of them, but when you start to separate the pieces from each other you discover there's no way to rearrange them without causing a mess. For example, you might have some code that calculates the shipping cost for a shopping cart, but you have no easy way of calculating the hypothetical shipping cost for that same shopping cart if the customer added another product. It sounds crazy, and it is, but this type of situation is embarrassingly common in programming.

This is not how things were supposed to be. It's very dispiriting to spend a full workday, as is not uncommon, trying to figure out how to place a button inside a box instead of next to it. Just because you know how to put things together one way, doesn't mean you understand how to put them together some other way. There's a common example programmers use to convey what they wish programming would be like: Lego bricks. "The pieces just snap together, like Legos!" is a common claim for new programming languages and tools. That's how we all want programming to feel, and how it seems it could be: inifinite possibilities in combining and re-combining small pieces of functionality into beautiful, cohesive programs. Pick out your bricks, with the right sizes and colors, and snap them together to form spaceships, parks, and dairy farms. This ideal usually goes under the name of composability: the ability to compose smaller pieces into bigger units with confidence, knowing that the pieces will not cause each other to blow up or jam.

"Nobody move, nobody get hurt"

In mathematics, things generally snap together beautifully. One reason for that is something called closure, which is the principle that if you have a thing of a certain kind and modify it or combine it with some other thing, you get the same kind of thing back. Numbers are the most common example of this. Take the integer 3 and combine it with the integer 7 using addition: you now have 10, another integer. In the same way, the beauty of Lego is that every brick can be combined with every other brick, and you can keep combining the bigger, compound pieces. Alas, that's not generally how things work out in programming. Unless you take special care, your code will be like a factory full of little machines that all produce different kinds of things. The output of one machine can't be fed as input to most of the other machines (or even to itself). In the worst case, once you get the little machines connected up and at least mostly doing what you want, you become hesitant to touch anything lest it all falls apart.

So, the right thing to do is clearly to steal whatever we can from mathematics and bring more of that Lego snapping fun into programming. It just so happens that an excellent example of mathematical programming is hidden in plain sight of most programmers, in the good old SQL databases most of us work with (in some cases grudgingly) on an almost daily basis. To many, SQL is a creaky old relic from a bygone era (the 1970s), a dinosaur incongruously still roaming today's computing landscape. In that view, the prevalence of SQL is one of those accidents of history, something that just happened to appear and become popular at the right time and infiltrated everything to the point that we can't get rid of it. Some years ago, I thought of writing an article about the curious fact that our whole civilization runs on this quaint old beast of a computing paradigm. Then, slowly, I started to understand what SQL is really about.

The Relational Model and Pretty Wrappings

SQL is the interface language we use to query relational databases. "Relational" refers to the relational model of data, which in turn is based on fundamental concepts from mathematics and logic. Far from being some primitive solution cobbled together in the dimness of a less well-informed age, this paradigm is very elegant and has a great deal of Lego-ness to it. Unsurprisingly, this has a lot to do with the principle of closure: in the relational model, there is really only one kind of thing to work with, namely sets of "tuples" (a bunch of values that belong together, such as a person's given name, family name, and age). You can modify and combine these sets of tuples, but all you ever get back are more sets of tuples. It's tuples in, tuples out, all the way. You get to decide on the shape and size of your Lego bricks (tuples), and you get a handful of ways to modify or combine them (operations), and from these humble materials you can piece together programs to cover most of your needs - not quite everything that is required in a typical software system, but a suprisingly big chunk of it.

(As a side note for the technical reader, the main attraction of concepts like semigroups, monoids, and monads is precisely that they make otherwise unwieldy code algebraic, ie formed into blocks that are closed under useful operations.)

Now, some twenty years ago, a lot of people thought they had found something better than the relational model. Some tried to get rid of relational databases altogether, but most ended up wrapping the relational model in layers of code that felt more familiar to them. Many of these pretty wrappings do manage, to varying degrees, to preserve some of the elegance of the relational model, but in the end they obscure the clarity and simplicity of the relational model. (The ORMs - Object-Relational Mappers - I mentioned earlier is one, particulary clunky, type of wrapping.) To me, this is like someone who is in possession of an ergonomic, well-crafted keyboard but decides never to type on it directly, but only through a complex, ad hoc apparatus with fewer buttons. Convenient in some situations, but at the cost of forgetting how to actually use a keyboard.

Relational Algebra Lands Me a Job

And so we come to my own growing frustration with database wrappers, which reached its peak around five years ago. I was already interested in the use of formal logic as a basis for programming (more recently I started a podcast on the topic of logic programming), but I had somehow failed to fully appreciated that the good old work-horse SQL is a fine example of just that. I decided to investigate the best database wrappers accross all programming languages, to find out what the best approach was, but gradually I came to the conclusion that even the best ones (shoutout to Quill) add little to what SQL databases, properly handled, already offer. At long last, I started to see the beauty of the relational model. I became an advocate of shedding all the layers of wrappings and doing as much programming as possible as close to the database as possible, using pure SQL most of the time.

There is one concession that must be made, however: although the relational model is very lucid, it is nevertheless true that SQL itself is not a perfect incarnation of its principles (just decidedly better than most of the supposed improvements on it). On a deeper level, the kernel of the relational paradigm is relational algebra, a pure mathematical model of how to structure and query data. SQL fails to live up to that elegance on some counts. The next step in my journey, the one I'm still on, was to more fully understand relational algebra, and to look for ways to program in a way that adhers to it more closely than SQL. Among my findings was a little software package called bmg, which purported to implement pure relational algebra as an interface both to SQL databases and other data sources. It looked like a research project to me, something to check back on in the future perhaps. Inspiring but probably not fit for practical use. I "starred" the project on GitHub and every now and then I'd get an email notification about updates and bug fixes.

Fast-forward to the spring of 2020. I had gone back to consulting after a few years of being an employee and was looking for new interesting projects to work on. One fine day, I was going through some old notes and opened up that anti-ORM post I mentioned at the beginning, thinking it would be interesting to re-read it. I soon noticed that the author was none other than the creator of bmg, the relational algebra package, a certain Bernard Lambeau. And this sage was not walled up in some academic institution, but out and about running startups, Klaro being one of them.

And here is the part where I tell you how to land a great job in software through the power of relational algebra (via LinkedIn):

Hi Bernard - really like your old posts on revision-zero, and have been following your work on bmg. So when I saw that you have a startup and looking for new team members I had to get in touch! Would you consider a dev working remote? (From Sweden.) Great fan of db-centric programming and logic.

I soon discovered that Bernard and I have quite a few things in common when it comes to how we prefer to build software, and I also learned that bmg is used in production in Klaro and other projects. After some back and forth, I was lucky to get a chance to work on Klaro - and to learn bmg more thoroughly! The use of bmg is particularly apt in the context of building Klaro, since Klaro at its heart is really a database which gives regular users some of the power to view data from many different angles that relational algebra affords programmers. But that's a topic for another blog post.

Takeaways

1. Always be taking notes
2. Cold-posting people is a good way to get ahead in the world, especially if you take an interest in their obscure open source libraries
3. Relational algebra is good for you, for the world, and for your career
4. LEGO®