this post was submitted on 19 Jul 2025
839 points (99.8% liked)
Greentext
6788 readers
1447 users here now
This is a place to share greentexts and witness the confounding life of Anon. If you're new to the Greentext community, think of it as a sort of zoo with Anon as the main attraction.
Be warned:
- Anon is often crazy.
- Anon is often depressed.
- Anon frequently shares thoughts that are immature, offensive, or incomprehensible.
If you find yourself getting angry (or god forbid, agreeing) with something Anon has said, you might be doing it wrong.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Eh, I've had a number of coworkers who ended up working for Microsoft. They were all either terrible programmers or utterly unmotivated to do much actual work. One of them was a guy who did not show up even once at my company for more than a year but wasn't fired, for some unknown reason. Microsoft's inability to produce much of anything in the way of good software is no surprise to me.
Personally, I think it has a lot to do with Microsoft's being one of the pioneers of TDD (Test-Driven Development). The idea is that you have a small number of good, experienced developers writing suites of automated tests, coupled with a large number of inexperienced or inept developers who try to write code that passes these tests. Whatever code happens to be good enough is kept and the rest is tossed away. In this model, there is some advantage to sheer numbers even when most of the people you're hiring are pretty terrible at what they do (although these are exactly the kind of employees that can be - and are being - easily replaced by AI).
It's funny to imagine real-world engineering using an approach such as this. Like, imagine a world where they let anybody off the street attempt to build bridges, while the experienced civil engineers spend their time trying to knock them down. You might get a few bridges that actually worked, but your rivers would be clogged with the remains of all the failures.
Is it well known that this is how Microsoft practices TDD? Because that’s not the normal practice for TDD. TDD just means you write tests first, but normally the same person writes the tests and then makes them pass.
I was gonna say, that's not like any form of TDD I've ever come across.
I've never heard TDD described like this. I cannot even understand how this works from a project standpoint.
"We need a new feature. Todd's written the test already, so everyone just have at it with your fastest implementation; whoever passes first, gets to go to prod!"
It's insane, but it almost makes sense. If you have good tests, code that passes them should be a good enough start. Spend good money on devs that can write said tests, and then you can use them to drive productivity evaluation for those who aren't. As a bonus, if you need to "shed" "controllable" expenses, you can fire the cheap devs.
I hate it.
Reminds me of MCMC sampling, or straight up rejection sampling.
My biggest issue with this kind of "TDD" is, you pay two people to write the same code twice. Test-driven can work if done correctly, but this just stupid.
I had a coworker who was obsessed with writing unit tests. He was the lead developer on a project which was supposed to take three months and at one point had gone past the two year mark without producing working code. At one point during a meeting with the increasingly (and legitimately) unhappy client, he blurted out "but we've written six times as much test code as actual code!" He was not exaggerating either. Believe it or not, this made the client even less happy.
I think my last programming job (a couple of years ago) had a healthy relationship to tests. You had to do meet a certain coverage percentage, and if you had particularly interesting pieces of code, they should better be tested. But they acknowledged that 100% is just stupid, and that testing the same boilerplate over and over was a waste of time.