Stefan Schick's personal Blog

A lot of popular software is loud. It shows me notifications, popups, and all the new features I don’t care about. I want to make the case, that quiet software is better. Quiet software is there for me if I need it, it does its job but otherwise gets out of my way as much as possible. Let me elaborate: I grew up with an Atari ST, then got my first PC with Windows 95, and soon after switched to Linux. Back then on the Atari ST, it was reasonable to have only one program open. Even with Microsoft Windows 95, this held up because the hardware and the many crashes were the limiting factors. The programs were single purpose and cross communication between programs and the operating system was rare. To display additional information the status bar within the program was used or a message box was created by the program.

One of my clients has a large C# dotnet core codebase. It consists of many NuGet packages that in part depend on each other. Overall not an ideal position to be in. When implementing a feature typically, multiple NuGet packages have to be touched, rebuilt, updated and tested. Sometimes this leads to conflicts and inconsistencies between NuGet Packages with specific Versions, or Bugs in general. One of the errors we sometimes hit is the “Package downgrade”-Error with the error number NU1605.

A while ago I was testing sway as a wayland compositor. The goal was to make the switch to wayland for my daily work. Unfortunately, this didn’t quite work out. I have the feeling, that wayland isn’t quite there yet. A lot of things work, but it still feels cumbersome at times. Anyway, while testing sway, I noticed that the tray wasn’t working. When looking for the reason I stumbled upon the planned swaybar tray features. A bit disheartened I thought about what are the essential things I need. The most important things for me are battery information and the current date and time.

Bugtrackers, tickets and squashing bugs is a process essential to every software engineer and it is expected, that you know the process. But somehow there is no proper description of the process and how it works. All knowledge about squashing bugs is self-taught or delivered in tales full of nostalgia. In this article I explain my strategy on how to process bugs in an efficient manner. The goal of this process is not to close as many tickets as possible, but to solve the problems of the users and improve the software. Closing tickets and fewer tickets overall is a side effect.

Over on HackerNews was a question about “Best practices for hiring software contractors. As I have been a contractor for about 10 years now, I will give you some insights in my approach when it comes to clients and getting hired for a job. I am living in Germany, not everything I write might apply to the situation in your country. Context There are many contractors out there with varying skill levels. Some are good, some are bad, others are good in their niche, but suck at everything else. I consider myself a good one. At the core I am a generalist and have done a lot from embedded to web and frontend to backend. But I have my preferred niches in manufacturing systems engineering and I love Software Architecture. By principle, I do not offer my services on fiverr or upwork, as they are budget driven and are for the most part not in my price and project size class. Instead, I prefer direct customer acquisition as it offers the highest rates or recruiting agencies if I am lazy on the marketing front but want a customer with a big name. The Projects I am involved in have usually a length of one to three years.

Last week I was on the shooting range learning how to shoot clay pigeons with the shotgun. When our trainers explained the process I was a bit irritated at first. They explained to us how to raise the weapon to get into firing position, what to do with our eyes, and how to move the weapon for a moving target. But they didn’t talk much about the hitting itself, they just gave us feedback about the technique and if we shot too low or too high.

Recently my priorities shifted from work for money to more leisure time, hobbies and contributing to causes important to me. As I am still developing software during work, I didn’t want to write code during my free time, too. Instead I thought it would be a good idea to contribute to open source by cleaning up bugtrackers, triaging bugs and discussing solutions. So I looked around and found some bugtrackers for software I use. Much to my disgust I found that nearly every bugtracker has thousands of open tickets, many open for years without change. It feels like a special kind of hell. Maybe I am only using the wrong software?