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

521–530 of 697 posts

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

#521

Post by fleshdaddy »

Anon1096 wrote: post #442
com2kid wrote: post #192

Earlier quoted context omitted.

> From another former Az eng now elsewhere still working on big systems, the post gets way way more boring when you realize that things like "Principle Group Manager" is just an M2 and Principal in general is L6 (maybe even L5) Google equivalent. Similarly Sev2 is hardly notable for anyone actually working on the foundational infra. Before the days of title inflation across the industry, a a Principal at Microsoft wa…

One of Microsoft's problems is their pay is significantly lower than FAANG and so you very very rarely see people with expertise in the same verticals jump to Azure. I get that "the deal" at Microsoft is lower pressure for lower pay but it really hinders the talent pipeline. There are some good home grown principals and seniors, but even then I think the people I worked with would have done well to jump around and ge…

Yeah the deal has also changed. Right as I was leaving the messaging started changing a lot and there was a clear top down “you all need to work harder”. They hired an ex Amazon guy to run my org which really drove the message home.

To be fair though I think Microsoft has decided they are fine with rank and file being mediocre. I don’t know how interested they are in competing for top talent except for at the top.

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

#522

Post by dpark »

senderista wrote: post #506
caoilte wrote: post #481

Earlier quoted context omitted.

Unit tests are just as important as integration tests as long as they're tightly scoped to business logic and aren't written just to improve coverage. Anything can be done badly, especially if it is quantified and used as a metric of success (Goodhart's law applies). Integration tests can be just as bad in this regard. They can be flakey and take hours, give you a false sense of security and not even address the comp…

“Premature abstraction” forced by unit tests can make systems harder to maintain.

Inability to unit test is usually either a symptom of poor system structure (e.g. components are inappropriately coupled) or an attempt to shoehorn testing into the wrong spot.

If you find yourself trying to test a piece of code and it’s an unreasonable effort, try moving up a level. The “unit” you’re testing might be the wrong granularity. If you can’t test a level up, then it’s probably that your code is bad and you don’t have units. You have a blob.

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

#523

Post by dpark »

bob1029 wrote: post #385
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…

> first cover everything with tests Beware this goal. I'm dealing with the consequences of TDD taken way too far right now. Someone apparently had this same idea. > management who do not fully understand the problem nor are incentivized to understand it They are definitely incentivized to understand the problem. However the developers often take it upon themselves to deceive management. This happens to be their incen…

Customers don’t care about your testing at all. They care that the product works.

Like most things, the reality is that you need a balance. Integration tests are great for validating complex system interdependencies. They are terrible for testing code paths exhaustively. You need both integration and unit testing to properly evaluate the product. You also need monitoring, because your testing environment will never 100% match what your customers see. (If it does, you’re system is probably trivial, and you don’t need those integration tests anyway.)

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

#524

Post by bwfan123 »

yoyohello13 wrote: post #27

I don't know if any of this is true, but as a user of Azure every day this would explain so much. The Azure UI feels like a janky mess, barely being held together. The documentation is obviously entirely written by AI and is constantly out of date or wrong. They offer such a huge volume of services it's nearly impossible to figure out what service you actually want/need without consultants, and when you finally get t…

I have been a frustrated user as well. Their services seem to be held together by duct tape. For instance, an online endpoint creation failed after 90minutes with internal-error and no clue what the error is. Support tickets are routed overseas to consultants who dont have a clue - and their job is a daily email keeping the customer warm. All-in-all, and as OP says, its amazing that it is still hanging together. Some services work reliably but not all.

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

#525

Post by markus_zhang »

lokar wrote: post #38
Anon1096 wrote: post #24

The post is so dramatized and clearly written by someone with a grudge such that it really detracts from any point that is trying to be made, if there is any. From another former Az eng now elsewhere still working on big systems, the post gets way way more boring when you realize that things like "Principle Group Manager" is just an M2 and Principal in general is L6 (maybe even L5) Google equivalent. Similarly Sev2 i…

I think he did kind of point at the lack of seniority in the org, so I'm not sure he was trying to exaggerate with the titles. I'm really struck that they have such Jr people in charge of key systems like that.

Juniors love to hack out new things and in the mean time they can take the blame if needed, fair trade, won’t you say?

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

#526

Post by markus_zhang »

whoamii wrote: post #214
Anon1096 wrote: post #24

The post is so dramatized and clearly written by someone with a grudge such that it really detracts from any point that is trying to be made, if there is any. From another former Az eng now elsewhere still working on big systems, the post gets way way more boring when you realize that things like "Principle Group Manager" is just an M2 and Principal in general is L6 (maybe even L5) Google equivalent. Similarly Sev2 i…

For reference, author was a Senior Software Engineer, ie. mid-level engineer.

He was from the kernel team, though. I always put their experience x2.

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

#527

Post by greatquux »

bigbuppo wrote: post #14
tantalor wrote: post #8

Earlier quoted context omitted.

> 2 instances of Outlook That's 2 too many.

They should have used the third outlook they didn't know about... Outlook, Outlook (new), and the well-hidden Outlook (classic) that actually works.

"Classic" was never very stable to begin with, and seems to be getting less stable every monthly patch cycle. Decades-old problems remain unfixed, and "new" Outlook still doesn't have all the features of the old one (or compatibility with in-house programs that use MAPI integration, or COM add-ins). "Classic" must have been such a spaghetti-fied mess that they thought they couldn't actually fix it at all and needed to replace it. But I'm not sure that's really the solution... is it ever?

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

#528

Post by bluGill »

senderista wrote: post #506
caoilte wrote: post #481

Earlier quoted context omitted.

Unit tests are just as important as integration tests as long as they're tightly scoped to business logic and aren't written just to improve coverage. Anything can be done badly, especially if it is quantified and used as a metric of success (Goodhart's law applies). Integration tests can be just as bad in this regard. They can be flakey and take hours, give you a false sense of security and not even address the comp…

“Premature abstraction” forced by unit tests can make systems harder to maintain.

the problem is people make units too small. A unit is not an isolated class or function. (It can be but usually isn't) a unit is one of those boxes you see on those architecture diagrams.

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

#529

Post by senderista »

bytefish wrote: post #319
jamwhite wrote: post #139

This read was a blast from the past. I'm not going to comment on much from OP and instead give a little of my experience there. Straight out of college in 2017 I joined the Compute Fabric Controller (FC) org as a SWE on an absolutely wonderful team that dealt with mostly container management, VM and Host fault handling & repair policies, and Fabric to Host communication with most of our code in the FC. I drove our te…

The first and most important lesson, that I try to each every young developer starting in the industry: Go home after clocking in your hours negotiated in your contract. Drop your pen. Go home. Sleep well. And I hope, that every sensible senior developer in here does the same. Lead by example. Maybe it would prevent a few burnouts in this industry. And if you are a manager, then send your people home after they have…

Good luck with that when you’re oncall.

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

#530

Post by dec0dedab0de »

breppp wrote: post #456
tremon wrote: post #435

Earlier quoted context omitted.

Windows is the only system that can effectively run on any hardware ...as long as that hardware is Intel-based (and a select few ARM-based boards nowaways). And the reason that it runs on all that hardware is because of Microsoft's business contracts with hardware vendors, not because of their software quality -- that's immaterial, as Microsoft generally does not write the drivers.

Compare the experience in Linux or Mac for getting some random no-name device working with Windows. A lot of it is the fact that the OS has created a very complex yet consistent system of device compatibility that was completely absent from all competitors who are still behind on that aspect or alternatively the choice of kernel design architecture

It's been like two decades since I used windows on a computer I own, but I always had a way harder time getting hardware to work with windows than I have with linux. I still shudder when I remember trying to track down drivers from different vendors, while avoiding the malware they shipped with it versus letting it just work.

edit:

I just remembered when I first used CUPS to configure a printer in 2003. It blew my mind with how easy it was, and I think that was the moment when I decided to start using linux as my primary desktop. Pre-Novell Suse at the time if im remembering correctly.

Post reply on HN