Once upon a time, in a life far far before now, I installed fancy cutting edge voip phones in every office of a computer science dept of a university, including the office of the dean. The dean turned to me and asked if I could setup the phone in such a way that he could connect it through his laptop. “Sure” I say and enabled internet connection sharing on his Ethernet adapter. It worked great in a demo in his office on Friday. However on Monday he stormed into my office, threw the phone on my desk and said this didn’t work at home. I looked puzzled, “but it worked on Friday”. I set it up again and it worked and returned the setup to him. The next day he says it just doesn’t work, so I ask for specific details. He said, “when I close my laptop lid the phone just disconnects”. I swear I looked at him like he had 10 heads. This is the dean of the comp sci department and he doesn’t understand that packet switching cannot occur if the device is off. And not for nothing, but I explained the setup to him.

today one of my pet peeves are people who cannot report issues. And I still experience this today while working with other distinguished engineers. I recently spent 2 months trying to figure out how to update running binaries in windows as part of an automatic update mechanism based on a request from an engineer. I spent the first week clearly delineating the problem with flowcharts demos etc. It wasn’t until I had almost completed the massive undertaking (windows blocks binaries from updating itself due to the way golang defers locking) when the engineer suddenly changed his request to only updating the dependent binaries and not the program itself. I had to rage quit that meeting because it reminded me of learning sendmail milters. Extremely steep technical curve that is obsoleted in a matter of months