What is a well known 'public secret' in the industry you work in that the majority of outsiders are unaware of?
What is a well known 'public secret' in the industry you work in that the majority of outsiders are unaware of?
What is a well known 'public secret' in the industry you work in that the majority of outsiders are unaware of?
You're viewing a single thread.
When IT says that an issue was caused by something someone else did, it's often them just passing the blame around. Source: I am an IT Director.
Gaslighting your users into thinking they broke something should be taught in school.
I had to stop myself from reflexively doing something like this today actually.
I was troubleshooting a severe performance issue in a test environment that was causing timeouts and crashes when large data files were processing for someone who isn't even on my team, so I could have easily passed the buck off on a random "someone". There were several factors, but I tracked down the biggest issue to a script that was taking like 3-4 minutes to run and even on that big of a file should have maybe taken 30 seconds max, though probably much less but only that much because it's a slow test server.
I found that the script was writing some text to the "standard out" log to basically help "someone" trace the flow of the complex logic (usually done as a fall back with scripting since there's no debugging capabilities). Basically it was just writing a couple of words for each record in the file. This file just happened to have a heck of a lot of records, so with the slowness of the system disk, it was exponentially increasing the time to process data that was all in memory at that point.
This is kind of a pet peeve of mine (log spam). Letting those kinds of things get into production causes nightmares when the huge volumes of production data are getting processed. It slows the system , causes the disk to fill up and crash applications, etc.
Then I looked closer at the script and realized that I'm the only one on any of the teams with the particular knowledge to have written that logic. I checked the git repository logs and sure enough it was me. I mean it vaguely looked familiar at first glance and I easily understood what it was doing, I just don't remember writing it. It was definitely in my style of writing though. I must have been really desperate to have used that tracing method and really tired to have forgotten to take it out. It's been a busy...decade....
So I had to admit to the person I was helping that the "someone" was me, and I'm planning to write up a "lessons learned" email tomorrow that only like 2 people will read, but it's still worth it if even one person learns from it.
Since I've been a lead, I've realized that the best way to get people to admit their mistakes and learn from them as well as be willing to ask for help in learning from them, is to admit your own mistakes. But it's only possible because I have a supervisor who gets me and understands that mistakes happen. In the past I've worked in such toxic places that making a mistake gets you fired or at least costs you a raise that at least covers cost of living so you're not making less money every year which are already extremely difficult to come by these days. Stacked ranking and other shitty management styles that make coworkers compete and/or put them in constant fear to try to increase their productivity just lead to people lying and not really caring about the quality of their work.
It's just like the shitty dog owner that beats the dog when they do something wrong, and doesn't pay any attention to them, much less reward them, when they do the things the person wants of them.