BLOG

• 01/05/2026: Good library design
• 20/12/2025: Finding problems to solve
• 17/11/2025: Please follow a standard
• 16/09/2025: Dog food is yummy

Good library design

Writing a library is different from writing an application where you dont have to worry about users experience with your codes API and internals. Here are the five principles I follow to ensure a library is actually useful:

Convenience vs Control: There should be a good balance between convenience (verbosity) and control (versatility). A good library tries to give the user both. A common solution to this is "Abstract by default, Explicit by choice". This allows the user to quickly use common functionality while also having the ability to do a specific task if needed.

Modularity: It is better to have a collection of small libraries that tackle their own small problem (they can of course interdepend) than to have a single big library that tries to do everything in one API. Trying to do everything under one API is not only hard for the developer but also bad for user experience. This UNIX-like approach allows you to mix and match based on your needs.

Delivery: How a user acquires the library and includes it in their project is very important. A good example of this is stb style libraries (easy to get and use) and raylib (one header and one .a file that are extremely easy to get). If your library is a nightmare to link or build, nobody will use it, no matter how good the code is. Always try to make your libraries single header or stb style if possible.

Self-discoverablility: Assume that the user doesnt know or wants to learn about the internals or the API of the library. Thus the API should be as intuitive and self-discoverable as possible. This doesnt mean the API should be very abstracted away but rather should be simple to grasp from the get go.

Minimal Dependencies: A good library should depend on as little as possible (ideally just the standard library). Every dependency you add to your library becomes a burden for the user to install and link while also making it less portable.

Finding problems to solve

Finding good and original ideas for software projects is a common challenge. The following are two methodologies I use to find project concepts that are both novel and practical.

Method 1: The super-niche intersection
Many software domains have well established and high quality solutions, even in niches. Building a direct competitor is often inefficient. A better approach is to explore intersection of two niches. The space where they overlap is what I call a "super-niche" where a dedicated solution is much less likely to exist.

Example: QMTIK

• Niche A: Libraries for quantized neural networks. This is a well explored field with solutions like TensorFlow Lite.
• Niche B: Minimalist, single-header, "stb-style" C libraries. This is also a well established niche.
• The Super-Niche: A minimalist, single-header, stb-style library for quantized neural networks. This intersection was largely unexplored.

Method 2: Solving an experienced problem
This is a more cliche approach: build a tool that solves a personal problem or improves upon a flawed existing solution. The key is to solve real problems and not to invent problems for the sake of a project. This requires a lot of exploration and research to find and build.

Example: EFPIX

• The Problem: Secure and resilient communication is critical in environments without stable infrastructure (e.g., military, space, disaster zones).
• The Flaw in Existing Solutions: Flood networking is a known solution for resilience but existing protocols often lack modern security.
• The New Solution (EFPIX): A protocol designed from the ground up to combine the resilience of flood networking with a modern cryptographic stack (end-to-end encryption, perfect forward secrecy, metadata protection).

Please follow a standard

Modern software is fragile and bloated. We spend more time managing dependencies and writing compatibility wrappers than we do solving actual problems. This is mainly because we dont respect standards.

Fallacy
There is a common misconception that "standards deter innovation". It is a convenient excuse that allows us to move fast and break things that leaves behind technical debt and incompatibility. But it is fundamentally false. Standards do not deter innovation but are the base upon which stable innovation is possible.

Reality
A standard defines the agreed upon way for things to interact but says nothing about the implementation. The C programming language is a perfect example. The ISO C standard defines the grammar, the keywords and the behavior of the language. But how you implement it is up to you. We have GCC and Clang both of which are innovative and compliant C compilers but are wildly different internally.

"But ..."
"But what if my idea is so new that the existing standard can't accommodate it"? This is a valid question for which there is a clear answer. You can:

• Evolve the Standard: Standards are not meant to be static forever. You can write proposals to the publishing body and help create the next version. This is how we got C23 from C89, or Vulkan from OpenGL.
• Publish a New Standard: If your idea is a true paradigm shift, then you have to do the hard work of formalizing it. Write a specification and create a reference implementation. This is how we got Wayland to challenge X11.

What you don't do is break the existing standard and call it "innovation". The most infamous culprits of this are the new Web "standard" and the GPU ecosystem. The web is a mess of a moving target specification and a tower of abstractions to keep it running. The GPU ecosystem is a bunch of proprietary drivers and half supported APIs. Both of these are plagued by technical debt that make them a nightmare to work with.

Dog food is yummy

"Dogfooding" is the practice of using your own products.
It is an extremely good way to understand the quality of life for your user and to find the friction points and missing features. When you design something you know you are going to use in the future, you are forced to make good decisions and improve the experience of the user.
I always try using my own libraries and tools which allows me to be in a constant feedback loop of improvement.