> So your issue is your secretary doing it's job poorly?
I think the real issue is the casual deception which you just fell for: It isn't "your" electronic secretary, and the thing it just did might actually be a "good job" from the perspective of those who control it.
> What is your experience of how employees are handling the barrage of major public scandals then?
For real problems, like Cambridge Analytica or the recent API token breach, by trying to fix whatever is broken. A lot of the other scandals honestly don't seem to have any basis in reality that we can discern, so we spend a fair amount of time looking puzzled, then shrugging and getting back to work.
> I can not understand how any semi-decent societal system can accept a situation of opaqueness and no accountability.
Part of it comes down to an effect that's been known for a long time with human-computer interaction.
Whenever you have a machine in the decision loop of a job, many workers WILL DEFER to the machine whenever there's a question of whether something is wrong or right.
By deferring to the machine, the workers absolve themselves of accountability and shift all responsibility to "the system". I think this is often deliberately "baked in" by management to customer service of all kinds. You can see this in a small way if you've ever had to call an internet service provider in the USA to deal with a billing mistake.
> Hell I just replaced thousands of older desktops with slower laptop chips — nobody noticed.
This is certainly plausible if these were mostly Office users but how confident are you that you'd know if they did notice? Most of the large IT departments I've interacted with would post glowing self-evaluations while the users had plenty of complaints and/or were doing their real work on personal devices. Depending on how the business is structured and the relationships, this can be hard to measure without a fair amount of effort — I've heard people say they weren't going to report something because they didn't think it was worth the effort or they were sure that the IT people would notice and fix it.
>I helped a lady on Friday at a midsized bank whose job it was to take a set of dates in an Excel file, search each one individually into an internal search tool, then Ctrl+f the result report and verify that every code listed in the original document exists in the report.
I happen to work in a midsized bank, and we have TONS of these sorts of manual processes. My favorite unintuitive fact is that 90% of them turn out to be some outdated compliance process that nobody remembered a person even did, and that is no longer necessary.
That also usually the reason why something is "too small of an impact". Having 2 engineers come in to figure out that something is obviously just busywork, and then try to run some political process to convince leadership, is very expensive.
> because I can’t figure out how that could happen and not be trivial to fix.
Oh, there are many ways this could be non-trivial to fix. For example, at Google, there is a section of review that employees don’t see. It’s visible only to managers and committees. So there could be something negative in this section. Now HR looks at remote work arrangement, to this review section and says “we can’t allow remote work with such feedback”. Employee non-the-wiser is befuddled about sudden change of heart while bureaucracy is working as intended.
Or maybe they figured out that he moved but didn’t report it in time. Now, they can sweep it under the rag, or raise issue of tax and benefit fraud and “start investigation”.
>Let's work with this. Are you feeling resentful because your need to be listened to? If the answer is yes, how about we take 15 minutes and you can explain the extent of the issues? If not, I haven't understood—could you try again?
I'm not sure what you're trying to show here, because just because you can write a positive reply to that here on Hacker News does not in any way change someone's actual trepidations with expressing that to their actual manager.
Plus the entire subtext of that reply is just "I don't want to acknowledge the possibility that I have made any mistakes, and so I am going to reduce your problems down to cliches."
> I spent hours in meetings to make sure everything is correct. Yet, sometimes it feels that no matter how much effort I put, people will just find ways to misinterpret it.
from reply below:
> I apologize if I got defensive, it is just that I put so much effort on being truthful, double-checking, putting disclaimers everywhere about every possible misinterpretation.
I just want to say: don't stop. There will always be some people who don't notice or acknowledge the effort to be precise and truthful. But others will. For me, this attitude elevates the project to something I will be watching.
> The phone screen is where I can screen the companies
Fair enough but remember that you may be screening not the company itself but some frazzled engineer who curses herself for agreeing to perform 4-th phone screen a week instead of insisting on writing code. Your impression of the company may be misleading.
> Ashamed that someone else's system doesn't work? I can't help you there. That's some deep psychological issue.
Personally I get angry in those situations... the larger the company, typically the more safeguard crap in place that's supposed to prevent those issues, the more pissed off I get. But that's just me. I get angry when I see evidence of poor/buggy quality in business software the more visible it is.
> More generally, I think the point of the original post, and the original comment, are that verifying that something was communicated successfully requires out-of-band actions. Physically demonstrating something, or watching someone demonstrate something, are both out-of-band: neither work over all communication channels, like user manuals, or phone calls.
Of course? That's the implication of not just taking someone's word for it in the context of an office environment.
> Even in-person communication is often restricted to make verification difficult: imagine if you're in a water-cooler meeting with another developer, and you mention that you think they should take a different approach to a certain problem. Are you going to follow them back to their desk to verify that they really choose to do so? Probably not: it's both incredibly rude, and a bad use of your own time. But there is nothing in the water-cooler conversation that you can really do to check that they'll take your advice.
That would be the case if it was a trivial matter. But for really important things, then I don't see a problem?
When I worked in banking, we'd get similar complaints about things of exactly as much importance as that complaint. We even frequently had people who would email such things directly to our CIO, and he would come downstairs and ask us about it. And we'd say, "Yep, that is a legit problem. Do you want us to drop all the mission-critical priorities to fix it?" He'd say, "No.", and go back to his office.
By all means, send them a bug report. But shaming a company because your bug report doesn't become their #1 priority? No thanks.
> I've watched direct reports operate as a "human command line", requiring precise syntax before they'll act. Don't be either of these type of people.
I've had managers give stupid orders, and seen them immediately backpedal when asked "would you write that down for me, please?"
So yeah, I'll definitely act in good faith but unfortunately I can't assume good faith on the other side, I occasionally need to be a human command line.
> Pretty sure management (without tech clue) have something to do behaviours like this.
Always the same bullshit with you people here. Could never possibly someone built a sub-optimal system -- it HAD to be management fucking with our good intentions!
I think the real issue is the casual deception which you just fell for: It isn't "your" electronic secretary, and the thing it just did might actually be a "good job" from the perspective of those who control it.
reply