Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decisions that eroded trust in Azure – by a former Azure Core engineer

isolveproblems.substack.com

Post reply on HN
Print view View original

411–420 of 697 posts

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#411

Post by rk06 »

axelriet wrote: post #284
rk06 wrote: post #207

Earlier quoted context omitted.

Hi, I hope you are doing good. From my personal experience, complaining about your manager to skip level manager is called Career Suicide. There is nothing good that can come out of it,, except getting fired.

It is, but “Microsoft runs on trust” they say. They also say the CEO’s inbox is always open, actually the CEO himself says it in the yearly mandatory training video on business conduct. So it should be safe, in theory, to openly speak out in the best interest of the customers, no? Rhetorical question :)

it is not. the real world says one thing and does another.

here is how real world tech companies actually function: https://www.seangoedecke.com/how-to-ship/

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#412

Post by pjmlp »

cineticdaffodil wrote: post #260
chii wrote: post #249

Earlier quoted context omitted.

unfortunately, what you will find is that unless you get lucky, the next ship is more of the same. The system/management style is ingrained in corporate culture of large-ish companies (i would say if it has more than 2 layers of management from you to someone owning the equity of the business and calling the shots, it's "large"). It stems from the fact that when an executive is bestowed the responsibility of managing…

Hierachy is the enemy of succeding projects and information flow. The more important and complex hierarchy in a culture the less likely it is to have a working software industry. Germanys and japanese endless :"old vs young, seniority vs new, internal vs external, company wide management vs project local management come to mind. Its guerilla vs army, startup vs company allover..

As someone on DACH space, the internal/external goes to the extreme of not being allowed any company infrastructure used by the internals, including some basic stuff like the coffee machine, or canteen.

I had team lunches that only happened, because naturally the team couldn't care less about the regulations, and found workarounds, like meeting by "chance" on the same place, and apparently there were no other set of tables available.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#413

Post by sakesun »

_lvbh wrote: post #229
sakesun wrote: post #124

> Few engineers could reliably build the software locally I've just listened to Longhorn story on Monday and have heard the same thing.

Could you link the story by any chance? I've been using Longhorn for a while and on one particular system, it has an odd tendency to corrupt XFS.

Probably this one https://www.youtube.com/watch?v=RpRZ8BQiiMo

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#414

Post by teeray »

idorosen wrote: post #213
branko_d wrote: post #205

I think this is especially problematic (from Part 4 at https://isolveproblems.substack.com/p/how-microsoft-vaporize... ): "The team had reached a point where it was too risky to make any code refactoring or engineering improvements. I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something." Once you reach this stage, the only escape is to first…

Or to simplify the product and rebuild.

“Rebuild” is also a four-letter word though at this stage too. The customer has a panel of knob-and-tube wiring and aluminum paper-wrapped wire in the house. They want a new hot tub. They don’t want some electrician telling them they need to completely rewire their house first at huge expense, such that they cannot afford the hot tub anymore. They’ll just throw the electrician out and get some kid in a pickup truck (“You’re Absolutely Right Handyman LLC”) to run a lamp cord to their new hot tub. Once the house burns to the ground, the new owners will wire their new construction correctly.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#415

Post by jjkaczor »

cjbgkagh wrote: post #133
vintagedave wrote: post #9

What are we reading here? These are extraordinary statements. Also with apparent credibility. They sound reasonable. Is this a whistleblower or an ex employee with a grudge? The appearance is the first. Is it? They’ve put their name to some clear and worrying statements. > On January 7, 2025… I sent a more concise executive summary to the CEO. … When those communications produced no acknowledgment, I took the customa…

As a former MSFTy it does sound weird to me too. I didn’t see what Axels level was but a lot of people work for Microsoft and not many of them can expect to email the CEO and get a response. It seems a bit like a crash out, not the first I’ve seen levied at Azure, won’t be the last. They probably think it’s a mental health episode, if you’re an important CEO crazy people will email you all the time and the staff prob…

While Microsoft is hierarchical - but it did encourage reaching out in a "flat" manner internally.

In my experience - a loooong time ago ago now - executive leadership would participate in high-level escalations/critsits for large/key customers on calls. I was just a lowly field-engineer - but over the course of nearly 4-years, was on calls about 5 times with some of the big-names from that era that everyone knows about... And they seemed to emit enough empathy with the specific customer situation to move things forward.

However - being on the "other-side-of-the-fence" (i.e. external, consulting with Microsoft customers - some of them who even spend $1.5billion/year in M365/Azure licensing) and assisting clients with issues and remediations for the last 10-years, things are no longer the same. No amount of escalation gets further than occasionally reaching some level of the product team - and it can take 8-12 months before that even occurs. Troubleshooting and deep-engineering support skills for cloud customers are typically non-existent, and the assigned resources seem to just wait until the issue resolves itself...

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#416

Post by pjmlp »

bayindirh wrote: post #371
dbdr wrote: post #242

Earlier quoted context omitted.

> I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something. And that, my friends, is why you want a memory safe language with as many static guarantees as possible checked automatically by the compiler.

They could have started with simple Valgrind sessions before moving to Rust though. Massive number of agents means microservices, and microservices are suitable for profiling/testing like that.

Visual Studio has had quite some tooling similar to it, and you can have static analysis turned on all the time.

SAL also originated with XP SP2 issues.

Just like there have been toons of tools trying to fix C's flaws.

However the big issue with opt-in tooling is exactly it being optional, and apparently Microsoft doesn't enforce it internally as much as we thought .

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#418

Post by pjmlp »

flohofwoe wrote: post #376
dbdr wrote: post #242

Earlier quoted context omitted.

> I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something. And that, my friends, is why you want a memory safe language with as many static guarantees as possible checked automatically by the compiler.

Did you miss the part that writes about the "all new code is written in Rust" order coming from the top? It also failed miserably.

That was quite interesting and now I will take another point of view of the stuff I shared previously.

However given how Windows team has been anti anything not C++, it is not surprising that it actually happened like that.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#419

Post by jazzypants »

mpyne wrote: post #144
CoastalCoder wrote: post #103

Earlier quoted context omitted.

I'd like to suggest calling him SECDEF, not SECWAR. IMHO the country should not capitulate to Trump's power grabs, even if Congress refuses to perform their oversight duties.

I'm sympathetic to the viewpoint but I'm not in the habit of policing the names people use for themselves. I've certainly done more than my fair share of jobs in the Navy where the office I was formally billeted to had long since ceased to actually exist as described due to office renamings. Often things as simple as a department section being elevated into a department branch and people using the new name even while…

These agencies such as the Department of Defense, whose secretary is...?

The department's name is *legally* the Department of Defense. If they want to change it, they can go to Congress and do it the legal way. They have a majority. There's nothing stopping them except for their disregard for the sanctity of the law.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#420

Post by bayindirh »

pjmlp wrote: post #416
bayindirh wrote: post #371

Earlier quoted context omitted.

They could have started with simple Valgrind sessions before moving to Rust though. Massive number of agents means microservices, and microservices are suitable for profiling/testing like that.

Visual Studio has had quite some tooling similar to it, and you can have static analysis turned on all the time. SAL also originated with XP SP2 issues. Just like there have been toons of tools trying to fix C's flaws. However the big issue with opt-in tooling is exactly it being optional, and apparently Microsoft doesn't enforce it internally as much as we thought .

> However the big issue with opt-in tooling is exactly it being optional,

That's true, and that's a problem.

> and apparently Microsoft doesn't enforce it internally as much as we thought .

but this, in my eyes, is a much bigger problem. It's baffling considering what Microsoft does as their core business. Operating systems high impact software.

> Visual Studio has had quite some tooling similar to it, and you can have static analysis turned on all the time.

Eclipse CDT, which is not capable as VS, but is not a toy and has the same capability: Always on static analysis + Valgrind integration. I used both without any reservation and this habit paid in dividends in every level of development.

I believe in learning the tool and craft more than the tools itself, because you can always hold something wrong. Learning the capabilities and limits of whatever you're using is a force multiplier, and considering how fierce competition is in the companies, leaving that kind of force multiplier on the table is unfathomable from my PoV.

Every tool has limits and flaws. Understanding them and being disciplined enough to check your own work is indispensable. Even if you're using something which prevents a class of footguns.

Post reply on HN