I am an amateur radio operator. In the US this is commonly referred to as a ham, or a ham radio operator. My call sign is KC1KCE, as issued by the US government through the FCC. And yeah, I can hear you now, a ham is the geek equivalent of a cross-fitter. How do you know someone is a cross-fitter. 'Cause they already told you about it. Hams are kind of the same.

This week I really drilled down on a bunch of stuff with my radios. I have a Raspberry Pi with a transceiver hat (an attachment that goes on top of the Pi, like a hat) that I use as a hotspot for DMR (Digital Mobile Radio). I added functionality for System Fusion, a second digital radio mode to my Pi. I also set up my HF (high frequency) radio to work with a local repeater on 6 Meters (what's known as a band, in this case frequencies between 50 and 54 MHZ). I took part in several nets (on air meetings) using several different radio modes.

Yes, I hear that too. What's all this have to do with databases?

While the time I spend figuring out and implementing these technologies doesn't immediately help me deploy better with Azure DevOps or understand how to capture query metrics in PostgreSQL, it does help me practice good troubleshooting skills. I make backups of my radio's programming (yeah, you can do that, and yeah, you REALLY need to run backups on your radios, just like your databases). I manage code the same way I would if it were database structures. Further, figuring out how to work the OS on the Pi translates back into work I do in containers, working with SQL Server on Linux and other stuff like that.

In short, learning about my radios helps me learn about databases. Learning about databases helps me learn about my radios. Learning helps you to learn better. Learning better helps you learn more. To a large degree, your brain is a muscle. Use it or lose it.