Hacker News Reader

Unfortunately this same attitude bleeds into consumer-facing customer support so often.

I'll find a bug, and message support about it.

Yes - I've cleared cookies, Yes - I've tried incognito, Yes - I've rebooted, Yes - I've tried a separate browser, Yes - I've tried a VPN, Yes - I've tried different DNT, Yes - I've tried incognito, Yes - I've tried rebooting, Yes - I've tried an entirely separate device.

Infuriating. I'm sure it catches plenty of tech illiterate people's garbage bug reports that are just their issue - but so often I'm left banging my head on a desk when I know it's an actual problem.

It catches tech literate people's bugs so often too.

I maintain my teams VPN, and I have a script that I ask people to run to generate logs when there's an issue. It checks connectivity, flushes DNS, restarts the VPN and toggles the network device off and on again, then checks connectivity again.

The only person so far who this didn't fix the issue for (on an engineering team) was someone who had another VPN client installed and running, despite their insistence that they had followed the setup instructions clearly. That person was an engineer working on infrastructure and online services.

I dont think this is the same problem.

Apple wouldn’t even tell me they refuse to ship a replacement AirPod (I have to make a repair appointment) until I went through their trouble shooting process.

The worst part is if they can fix my airpod, they will charge me $69 for the fix. If they can't, they will charge me $69 to replace the airpod. If I say its “lost”, they’ll make me go through “find my” and then charge $69 for the replacement. I’m considering putting it in a blender to speed things up.

I think you misunderstood this whole process. Airpods are impractical to repair so when you get it "repaired" at the apple store or mail it in, they are always giving you brand new airpods. If you don't have applecare, "repairing" costs the same as buying a replacement because that's exactly what you're doing.

My goodness, are you me? This mirrors my experience to a T, almost exactly when I’ve tried to change process for the better. By far the one that hits the most is be rude: “well, just start fixing things then.” It was a daily struggle to have to work around the nay-say and lazy and equivocation and it was so demoralizing knowing that there was a simple fix but people didn’t want to do it because it would out their incompetence and start to reveal the tremendous pile of tech debt they’ve built everything else on.

The most funny thing was that this was not a huge organization at all, it was small for the scale they were working at but certain individuals have ossified the culture to a point where you would have thought it was hundreds of others. So frustrating, day in and day out.

> leadership had totally lost control of the zoo

This kills me

So glad to see I’m not alone!

Regarding tech leadership:

Perhaps I've just been unlucky, but a rather depressing proportion of tech leadership that I have been under in the past appear to have seeked the role in order to:

1. Hide lack of engineering aptitude.

2. Put less work in.

If i'm on the right track with that, then it well explains why they don't care about cultivating a good engineering culture and let everything devolve into a zoo - i.e. everybody feels like everyone is out to get each other, no team work, rep farming, and all that nonsense.

Regarding getting work done:

I agree, I actually believe that it's the cause of the slow death of many companies: A gradual acceptance of nay-sayers, laziness, and "losers", that is to say an acceptance of people who just think that everything is lost, there's no point to fixing anything, and instead choses to spend their time placating why nothing can be done about anything.

It's depressing, and was traumatic for when I was working in those environments in the past. (I like to think) I'm a get shit done and deliver awesome products kind of guy, so these "loser" engineers and leaders are a true PITA.

It can be tough because a lot of the work I do that gets me or keeps me in a technical leadership position is building lieutenants. That necessitates me transferring ownership of things to them, so they can grow or at least demonstrate to the organization that they have adulting skills and need a raise.

That can look a lot like me trying to do less work. Most of the time what I’m doing instead is looking at problems we “didn’t have time for” but are about to bury us. I can only juggle so many balls at once. What’s your favorite color? <hands you one>

>people didn’t want to do it because it would out their incompetence and start to reveal the tremendous pile of tech debt they’ve built everything else on

All part of the great circle of (software) life. Once they pass on from the company, you'll rip out their old, ossified way of doing things, and then when your new purer way hits the hard reality of business requirements and other considerations that don't fit in the nice world of software abstraction, you end up adding patches and edge cases and caveats until your software ends up looking a lot like the old one. And then a new dev comes in and complains that your process is terrible and they could do it so much better...

I had level 5’s telling me this shit when I was a (mis-leveled) 3 and they were doing the management bullshit thing of “bring me solutions not problems” bitch what do you think a staff/principal engineers job is if it isn’t finding problems before they find us? In a code as packed to the gills with tribal knowledge people don’t even know where the problems live. They just see the problem.

They stopped saying this when I reminded them that if I knew the answer I’d have their job. They still never actually lead anything.

“well, just start fixing things then.”

Also a real problem when management and leadership discourage working outside the "standard process" and incentives punish working around it. The person responsible won't work on it, and anyone else who could resolve the issue won't because they know they'll get dinged for not following the process.

I very recently had to push back on a bug that wasn’t a bug in my part of the stack. If they wanted it “fixed” in my part, it would be a feature. (Enum values from an API being localized — these were hardcoded on the backend). IMHO, these should be localized in the client, which has the current locale (I do not have the current locale and no strings are translated from this API by this API).

That was pretty fun, but I don’t think generalizing “denying a bug” as saying we are being “lazy” is a correct assumption.

I agree, "denying a bug" does not equal "lazy", but rather "denying a bug one has created" does at best equal "lazy", at worst malicious (e.g. rep protection).

I had a similar experience adding new functionality to a web application. It was a simple enough feature that I was able to supply the English myself, but I knew enough not to provide the international copy, even though the only other language we supported was a language I studied in school. I asked the product manager a few times, then created a ticket assigned to them and sent them the link. Meanwhile, my code got reviewed and deployed, behind a feature flag of course.

As soon as they found out the code was deployed, the product manager asked if we could turn on the feature. I reminded them that the reason we supported the other language was that it was a legal requirement for our customers in a certain country. They said turn in on, nobody was going to notice except a big US customer who desperately needed it. So I did.

Within a few hours we had an enraged customer on the phone. Credit to the product manager, they took full responsibility, but the initial response from the founder/head of customer success who took the call was to walk straight to my desk and ask me what the hell I did.

I can only think of a few countries where there are legal requirements for two languages. Was this French Canadian by chance?

Yep, that was it.

Sounds like the four stage strategy of the Standard Foreign Office response in a time of crisis in the BBC show Yes Minister:

In stage one we say nothing is going to happen.

Stage two, we say something may be about to happen, but we should do nothing about it.

In stage three, we say that maybe we should do something about it, but there's nothing we can do.

Stage four, we say maybe there was something we could have done, but it's too late now.

Heh I am glad I have not had many colleagues like this, but 1-2 this is 100% their modus operandi. Even worse though is when management understands this and passively rewards it by not intervening. In one case it got so bad the employee was promoted because they finally shipped something new. A very short time after feature delivery (and being promoted), serious customer bugs started trickling in. Well you know what happened next, more gas lighting.

I'd like to say there were finally some consequences, but no. The office was thrown a curve ball with large layoffs. Now that I think about it, maybe my ex colleague masterfully planned the whole thing.

The problem of that is they get defensive because people at the top doesn't stop the starting of the Blame Games when a bug or issue is found. Bad managers (or founders) are responsible for not stopping or not caring to stop this game. As business owners they are being quite silly as such culture makes costs and turnover of talent go up (and margins go down).

am in the same boat and the ppl responsible for the issues are always busy denying . Some of these ppl have also got into management, so they have got management cover. The only way things get solved is if some other team takes over the codebase maintained by them, but the actual culprits are failing upwards and moving into management.

At 5.4% of U235 enriched U238 , it requires infinite mass to reach criticality. You will need at least 20% U235 to reach criticality and you will need hundreds of kilograms of the stuff.

Really? Most nuclear reactors require enriched uranium, which is uranium with higher concentrations of 235U ranging between 3.5% and 4.5% Did you meant prompt criticality?

Prompt criticality is the best criticality!