Very true. Though less “prestigious”, the most fun I ever had was actually working as an SDET in the beginning of my career at Microsoft in Azure. I would spend hours dreaming up corner cases on how to break dev code in a distributed systems setting and came up with (for that time) quite a few unique frameworks that helped catch bugs that would’ve otherwise slipped through the usual unit, functional and smoke test archetypes. Unfortunately, I believe this job function has been removed entirely within MS

> Unfortunately, I believe this job function has been removed entirely within MS

Azure customers like me all suspected this, it's funny to see it confirmed.

The lack of testing is glaringly obvious. I can "break" Azure by deploying trivial, toy architectures. I can't imagine what customers go through if they actually try to scale up to something bigger or more complex.

Wow. I have the exact opposite experience with TDD. I use TDD to set a specific goal, and to have the computer tell me almost instantly when I've reached it. Then I can unleash creativity in trying implementations, and know instantly if they've worked. Occassionally I'll get a lucky guess in that works. Such a great feeling knowing immediately that my intuition was right.

Testing obviously is essential to the final product but TDD kills creativity by stifling flow.

There are many other problems with TDD (caveat: it's a good idea for _some_ projects) besides "it's no fun". Watch the Jonathan Blow video on the subject for the details.

The classic example is sudoku, where all the TDD advocates failed to get there because they spent their time testing incorrect ideas instead of actually thinking their way to a solution. You can't build a moon rocket a step at a time, as they say.

https://news.ycombinator.com/item?id=3033446

But I do think if you're going to write sudoku you should start with an end to end test, i.e., a solved sudoku problem.