Introduction

I am a programmer, and I approach software as such most of the time.

On occasion, however, I approach it like an ordinary user would, and every time I do, I learn something. This is one of those things.

Lesson

Another lesson I learned recently was this: eat your own dog food.

If you don’t, you have no idea what works on your software and what doesn’t.

I wrote an implementation of bc, and even though it is not the best tool for the job, I use it. I don’t use a desktop calculator, nor a handheld one. I use my bc alone. (Unless I don’t have access to my computer.)

I have found more bugs than users have, and I have found more complicated bugs.

This is a very good thing. If users are not running into bugs as often as me, and I run into bugs very little, then users are not getting bit by bugs much at all.

Experience

Contrast that with Gitea, the software I use to host my code on git.gavinhoward.com.

You would expect that they would host Gitea under Gitea, right? Wrong.

To be fair, they have a list of requirements, and an argument can be made why they were right to wait.

But my experience shows that it still causes problems for users.

When I switched from an Arch Linux server to a Gentoo server (to more easily get ZFS), the migration of Gitea was the thing that took the longest.

In fact, it just simply wouldn’t work with Gentoo’s OpenRC. It would work fine if I ran it by hand over ssh, but I could not get it to start as a service under OpenRC.

Eventually, I had to write a small tool to force it to the background, and I have to run it every time I reboot that server. (It’s a small price to pay for a working setup.)

I don’t know if self-hosted Gitea would have helped them find this bug, since they would probably use systemd, but it might help.

Conclusion

Eat your own dog food. Seriously. If you can’t, what makes you think other people can?