What Code should look like


Software is something you must be able to trust. Nobody likes relying on things that will let you down when you least expect it.

To make sure that software I write "just works" I eagerly test the code I write. I generally use test driven development as my approach to programming. If needed I facilitate fuzz testing to make sure nothing catches you unguarded.

When starting new projects from the scratch I prefer to use languages like rust and tools like the nix package manager to lay a solid foundation for reliability and reproducibility early on. But even for legacy projects there is a lot that can be done to bring them into a sane state where you can deploy without fear.


Many projects suffer from slowing down when the codebase gets larger. To cure this I use two primary methods:

Reusable modules

By organizing all software in reusable modules it becomes much easier to exchange parts of the software or to experiment with new ideas.


Behavior driven development creates tests from a user perspective instead of a technical one. This allows to easily check if we stay on track with the needs and vision of the user. On the other hand it allows to change the whole structure without fearing to shift away from the customer.

Another challenge that leads easily to unmanageable codebases is licenses. More and more all software depends on a whole lot of dependencies. Compliance with the openchain standard helps not to be caught in this rabbit hole.

User Friendliness

I strongly believe that software should adapt to the user and not the other way round. Therefore I base the UI strictly on user stories. Feedback by the user is always welcome to adjust the next version of the software.


In this ever more connected world security becomes a major concern. I regularly scan software dependencies for vulnerabilities. Additionally I use languages like rust that put emphasis on security.


Good documentation is essential for a welcoming user experience. Sadly it is one of the most neglected qualities in software development. I really care about documentation! Therefore I use techniques like literate programming and DDD to make sure the docs needed are always easy to find and read. In fact many of the tools I wrote for my own use revolve around documentation.

Open Source

Personally I owe a lot to open source. Many of the techniques I use come from studying open source projects, as well as nearly all of the infrastructure and tools I use.

When used rightly open source can benefit all involved.