mock.tech
geek by birth. linux by choice.
16 September 2026
Macbook Woes - Mutliple Monitor Problems
17 August 2024
Google TV Purchased Content Removed (Updated}
12 July 2023
Revenge of the Nano
22 May 2023
Chat Etiquette
At work last week on our intercompany daily update, a post was made discussing chat courtesy. The original message was to convey that instead of sending a greeting and waiting for a response, send with the greeting a question. So, instead of this:
Joe: Hello.
Frank: ...?
Joe: How do I do this?
Frank: This is is how....
This is preferred:
Joe: Good morning, Frank. How do I do this?
Frank: This is how....
The post received a load of responses. Many initially applauded the idea calling the first behavior a pet peeve. Many others countered with the opposite approach of perhaps a greeting and then asking if now is a good time for a question.
I happen to agree solely with the author's approach of asking the question along with the greeting. But I noticed that the answers did not take other factors into consideration. I believe these other factors are these:
- Assumed/understood behaviors
- Audience
- Efficiency
There are assumed behaviors of how the technology works. Chat or messaging is not equivalent to a phone call. Phone calls take more or complete attention to engage. Messaging was not designed to do that but to fill the gap of not interrupting someone's flow of work to get a response.
Messaging is not email, which has come to represent a document to be read and answered with a bit more time and attention put into it at a more convenient time. There is an implied delay with email in this culture almost to the point of considering it the same as snail mail.
Chat is a hybrid of these two: A more direct interaction than email without the complete interruption of a phone call (or video call). It's designed to be an efficient means of communicating.
The approach of the latter group in the above response pool, this is how they would prefer the messaging engagement to go:
Joe: Good morning, Frank. Do you have a moment for a question?
Frank: Sure.
Joe: How do I do this?
In this case, the question to ask a question is not only inefficient but also introduces the phone-call style interruption. Frank now has to take extra moments just to respond to the question to ask a question. But even when a question is posted in chat, there is assumed sometimes that there can be a delay.
Some of the responses included "ideas" of having a status of "unavailable," something which our messaging tool clearly has as a status indicator including a do not disturb option with even a place for text, e.g. "Busy until noon." Adding more to it would be redundant. I can also see when people are in meetings and not only that but when they are also presenting. The technology helps when the uncertainty of understanding of immediacy isn't obvious.
I think the audience also factors into this. With my team and more frequent conversation colleagues, I have no problem asking them messages even without a greeting. I would take a different approach with people I have never met or only have engaged a few times. Maybe a long time since the last interaction requires a greeting to renew the connection. There are different approaches to different people. I think the less familiar you are with the colleague, the more pleasantries.
Efficiency is the biggest factor as I see chat. If I can know what you want as soon as I see your message, the quicker I can respond. More than that, I'm less interrupted and definitely less derailed. There are some who just ping me with a greeting:
Joe: Hello.
I'm in the zone. My brain is deep into some logic and needs to stay on track. Waiting for a response from me now requires my full attention. (Phone call style interrupting in effect.)
Me: Yes?
I switch back to my train of thought to not lose it. Anywhere from a few second to a few minutes later comes the actual question. Now comes my second derailment...and aggravation mainly because it could have happened like this:
Joe: Hey, what's the name of the Python library we decided to use for the project?
Me: pandas
That entire engagement took at most 10 seconds to process and answer. Maximum efficiency achieved! I'm still in the zone. And if I choose to engage more on the subject, I can.
The first approach might seem kind, but here is what you are really communicating to me:
Joe: Hello. [I am more important than what you are doing so I need your full attention to me so I can ask even the simplest of questions.]
Me: Yes? [If you had asked the question, we'd already be done with this. You are now being selfish.]
I get that different people need more interaction and this one-line exchange seem rude. So, I think the best way to approach this is this way: When you engage me in messaging, be efficient. Ask the question without having me respond or pull it out of you. It might feel rude, but it won't be. It will be efficient!
15 March 2023
Fedora and Radeon HDMI Sound Issues
I have recently moved my desktop system into a rack mount case and rearranged my office. There were a few changes I ended up making because the rack case I ordered is a little short on depth. I ended up replacing the Gigabyte ATX motherboard with Intel CPU to a mini-ITX board with an AMD CPU which fits better. I transferred the hard drives and everything was working just fine...except for sound.
I spent a good bit of time tracking this down. The audio devices were recognized, the sinks were all operational (I could see activity on the meter in the sound settings), but there was no actual audio through the TV which was my monitory. All this had worked with the same equipment under the Intel resgeme.
My searching online provided no real help. I had a friend from the Fedora IRC support channel check things for comparison. But we couldn't find any real differences after two days. Being still frustrated had me checking Google results again.
I had found this page and started to look it over this morning: https://bbs.archlinux.org/viewtopic.php?id=256989. It got me thinking about Alsa configurations which are part of an older configuration possibly left over from upgrades. I had my friend check his /etc/modprobe.d/alsa-base.conf for what he had. He didn't. Mine had some options.
options snd-hda-intel model=generic
28 February 2023
Better Logging for the Best Sleep
I enjoy my sleep. An uninterrupted night after completing a coding project and having it deployed into a production environment is some of the best sleep I can have.
Being woken in the middle of the night because my code is failing in production and the support team not knowing the cause is something I have learned over the year to try to address long before my head hits the pillow. My logging should help them understand if the problem is really bad code or really something else such as a network problem or bad data. Well constructed logging can point the spotlight on the right place to look.
I was going through logs of some automation software at work trying to find a flow to the process. I will admit I did not know the package that well, so I was trying to gain an understanding reading through the logs. I've found using an application's logs to be helpful to understanding how it works without taking a class on the software. This got me thinking about how I log my own code. I've been writing log statements for years, but I know I could always improve my own logging skills. The following aspects are a few things I've learned over the years.
Logging is communication
Relationships are always better with good communication. The clearer the communication, the better the relationship. Assumptions can be made when it comes to believing what the code is doing, and we all know what is said about assumptions. In fact, the logical flow one expects might actually be part of the problem which logging could reveal. Being explicit when logging to remove any guesswork will save so much time when troubleshooting. Log clearly and concisely. Get to the point.
Understand the levels
Logging generally has about five levels: Debug, Info, Warning, Error, and Critical. And most loggers allow for customizing these levels or even adding levels among these defaults. Knowing what goes into a general flow of knowledge when reading logs and what belongs at the debug level should be obvious, but it might take a little time to make those judgment calls. At the Info level, I normally want to give more of an overall stepping through the code at points which mark functionality so that a first pass of the logs can help me at least see where in the code it is failing. I will throw in more variables and values into my Debug level statements when I need to see beyond the obvious logic. Warnings are for giving notice of things to not do or things which could be done better. Errors should be obvious as are Critical responses.
Logging is documentation
To be clear, logging does not replace documentation. It is a form of documentation. It goes hand-in-hand with documentation. Instead of explaining how the code functions, it shows how the process flows. It's a real-time walkthrough of the logical execution of the code. It can tell the story of what the program is doing while you watch it play out before you. If you consider it a part of the of the documentation, how you construct the statements might vary a little from what might seem obvious when in the middle of coding.
Another idea is to combine the documentation with the logging. Sometimes it is better to put longer explanations and suggestions for solving in the actual documentation and use custom codes in the logging to direct the support team to text that will give them a better understanding of the causes and outline the solutions to take.
Write for a larger audience
Sawing logs is an expression defining heavy sleeping. But when someone in a support capacity who does not have an intimate knowledge of the code, what they have in the logs can be enough for them to know what is wrong or leave them confused even a little bit which will prompt a next level call to the development team and possibly the developer.
My approach to logging has always been to write it so that no one needs to call me in the middle of the night because they have reached a point where it cannot be solved by them. In most cases, other pieces in the system could be the cause and easily determined with clear logging. When certain common problems have been experiences, adjusting the logs to better pinpoint the place to check and even suggest a course of action can help keep notifications at bay.
Keep it safe
Logging is generally put on a protected file system (or it should be) and/or ingested by a secure logging service, but logging credentials is generally unnecessary. Login ids should be enough to know which credentials are being used. Sometimes connection strings logged as a lump of information. Measures should be taken to mask passwords in those blocks of strings. I've seen functions built to parse that output before it's put out to mask the sensitive information. Knowing again the audience who will view the logs should also be considered for this.
I'm sure more could be said about logging. Clear and thorough logging can keep you sleeping when your code is being reviewed by a support team. Support teams can do their jobs more efficiently and effectively with skilled logging. Developers who will manage projects you leave behind will herald you wise. It should be every developer's goal to become a master at logging.