If I had to justify myself every time I took the basic initiative of fixing errant, problematic or poorly performing code just because it wasn’t ordained and blessed for me specifically I am out the door SO fucking fast…
Happy to have discussions and elucidate to others the change, and make whatever documentation necessary available, but if some leader somewhere things I’m a “problem” for merely having done the work…okay, let me solve that problem too: bye.
That’s an environment with serious trust issues manifesting as micro-management and I’ve got a severe case of post-micromanagement-stress-syndrome.
I think where the valid problem is in terms of priority.
Sometimes engineers “feel” the need to refactor something that’s not related to a high priority project and end up burning days as they weren’t experienced/competent enough to really know where that string they pulled lead and got stuck fixing newly failing tests etc. and in the examples I have in mind the context isn’t the usual “product feature must deliver pressure”, it’s actually pure engineering project, where we had to rearchitect a system before our scaling hit a brick wall, so interesting engineering work by engineers for engineers and still some folks just chase squirrels.
I totally love the freedom I’ve enjoyed to fix things at my discretion in my career, but not everyone is good balancing the time/place or “picking your battles” and sometimes you gotta reign it in in others or the stuff that needs to get done won’t be.
I’m left wonder at what point does the “give a man a fish/teach a man how to fish” method of pedagogy apply in terms of ‘acting like a human’ in this context?
Asking as someone who otherwise generally agrees that there are some truly poorly written errors and exceptions out there, but has also been on the admittedly frustrating end of the constant requests for help deciphering error messages that were very plainly stating what the problem is for someone who didn’t even try looking for the fishing rod.
Sure, clearly there are people who will never try, or learn, but in general as an industry I feel like the wast majority of errors are very very far from good.
Few error messages are written well, has good formatting and are self contained (can be used to fix the issue without having to seek further information elsewhere). Sometimes you see errors that contain one of those elements, but rarely all of them.
There has been an effort the last few years improving compiler errors for some languages, but those same improvements have not reached applications.
I’m not seeing how what the message already is any less direct or clear than what you’re saying it should be? It straight up tells you it can’t find the var and what to do about it.
Can you help me understand what isn’t clear about the message as is, or maybe point out the ambiguity to someone who just isn’t seeing it? I want to write better error messages but I share the frustration of the above poster. The message tells you specifically what to do, but you’re coming back saying it’s not clear.
I think the original error is quite clear, under normal circumstances.
Not OP but I've noticed that people often get brain fog when something goes wrong and are often need BIG, SHORT, WORDS to shake out of it. Or really anything that can shake them out of the 'idunno' state of mind.
But maybe if something like that became standard ut would no longet be a context switcher..
I think you're spot on, and I made a similar comment above.
It's easy to say "they can figure it out". Sure, in a restful state. But the people we're asking to take action already have a lot on their plate. Using plain, conversational language whenever possible with exceedingly clear steps means less mental exertion on the receiver. And since we need their help, anything we can do to make it easier on their end helps us.
These are fascinating responses to me, as with the example given my mind first went to someone for whom English is a second language. that group having trouble with this message I would understand, or at least have an easier time understanding having trouble, if even a very little amount.
For someone who was born speaking English and spoke it their entire lives, the example provided couldn’t possibly be more to the point in my opinion.
Though I agree overall with the general idea and that yes there are some pretty baffling and downright awfully written error messages and log entries that take a minute to grok (I just don’t think the example replied to is one of them).
Conversational errors can also be fatiguing. Often what you want is something short and dry that can be pattern matched. Compilers are pretty good at this because all their errors start the same way.
Error in file foo/bar.c, line 32, missing semicolon.
No conversation needed. These can then be complemented with more conversational language on the next line to explain why semicolon is needed. Rust is quite good at this.
Then there's the delightful (no, I actually mean the opposite) errors that g++ emitted (back when I last wrote C++ and compiled using g++), where I basically could go "OK, there is an error that was detected at line L, in file F; and I think it may be a type error", so a recompile with clang, so I can actually understand what the error was, so I could fix it.
I have had a similar thought but brushed it off as probably just me going through recency bias, but it does feel like I see their job posts a lot more than many others?
If you haven’t already checked out other work by Zim creator Jhonen Vasquez, his comics Johnny the Homicidal Maniac, and Squee, are excellent and full of very similar weird humor.
I made the conscious effort before leaving Facebook to trade phone numbers, addresses and birthday dates from the people I wanted to really wanted stay in touch with, and put them in my phone. This was all within the last three years.
I’ve sent birthday gifts in the mail, and I’ve gotten gifts in mail from these very people.
Sometimes, when I wonder where the convenience that gets talked about in the context of Facebook and “staying in touch” ends and a more delicate form of “you’re probably not as close to some of the people on your friends list as you think” (which was absolutely the case for me) begins.
It took really minimal effort on my part to find other ways of staying in touch, but I think maybe the key is you have to WANT to stay in touch with people?
I'm doing this too and it has been great for me in general.
I looked at my fb friends and thought to myself which people I really liked and would like to reconnect with. I messaged "facebook friends" I have not talked to in a while and told them it may seem weird but I really would like to reconnect. I have never done anything like this, as I am extremely prone to losing touch with people.
I ended up reconnecting with a few people in real life and it has been great. I also plan on sending cards and stuff.
Same. I've been pretty happy with Clay (https://clay.earth). They just rolled out a Facebook birthdays integration and between that and Linkedin / iMessage it has most of the people I care about seeing.
How about people own up to their mistakes instead of relying on random Joe who happens to be on call to fix it? I have been burned too many times by write only code written by some coworker who wants nothing to do with it. This is not just an on-call issue btw.
Sorry for my french but
Jesus fucking christ, thank you.
I was being woken up constantly at last job due to a bug in the application because I was the Devops guy and this is exactly how I was treated. I spent weeks finding contributing causes to frequent failures. Gathered all the evidence I could find and begged for a fix, I scheduled calls with the product team; I poured over documentation and diagrams “this is the problem, this is inherent to the way these requests are being made, until it’s fixed we have no choice but to throttle the app”. I recorded a ticket each time I got paged and linked back to the team who owned the feature.
What was infuriating in the end was finally being told that they knew about the problem long before I brought it up and even HOW to fix it; it was just consistently being deprioritized by people who had the means to influence the decision on “fix this” or “write new shit”. Eventually I just suppressed the application in PagerDuty and stopped waking up whenever it would fail.
SLA slipped, customers complained, I find myself in a meeting being asked very aggressively “what’s being done about this and why are you ignoring PagerDuty?”
I said I wasn’t ignoring PagerDuty and presented a log of 20 something tickets I created linking back to the original “Please fix this request”. I told my leadership “I’m not the one ignoring this problem, I have been trying to get this addressed and prioritized for months”.
Laid off a month later. It’s becoming a growing reason why I want out of Ops and never want to return to it: companies hiring Ops people and treating us like the kitchen sink for work the company is too lazy to actually address and properly prioritize through staffing, planning or both.
They don’t have to “notice” it. They don’t even have to see it.
Do you have an access badge to get into your company campus/building/suite?
My last job started tracking access badge activity to monitor and enforce RTTO compliance.
Found it funny to get nagged about not hitting the required minimum number by a boss who lived four states away.
Laughed all the way out the door and into a new company whose policy is “if you wanna wfh, then wfh. If you want to come to the office, be our guest.”