Morendil

Enjoying this a lot ! Possibly too much ;)

Not in-depth across the whole set; I picked apart one or two before coming to the conclusion that there was something inherently flawed in the whole approach of modeling study of the phenomenon after the protocol for medical intervention. That won't work; you can't do a double-blind study of TDD vs placebo. It's a conceptual tool, and as such requires knowledge and skill.

"Treating" a convenience sample of students with a 2-hour training session and trying to measure "performance" afterwards isn't going to yield much insight into what goes on in the mind of a seasoned programmer who's used TDD exclusively for a while. In my experience, the effects of such practice most definitely carry over to programming where you don't even try to apply TDD.

What convinced me to try TDD was a combination of naivete and desperation. What kept me at it was the undeniable, if entirely anecdotal, feeling of wrestling back control over the code I wrote. It's a more complex set of techniques than just "writing the test first", but it's hard to tease them apart and introduce them into your coding independently of each other.

Part of it is a commitment to evolving a program in very small steps, at every step having a whole program that works. Part of it is a set of instincts for refactoring, so that this program also has just as much "design" (if such a thing could be quantified) as is strictly necessary for the time being. Part of it is a habit of framing the next capability as a tiny experiment, with the test being the experimental protocol, and focusing your mind on just those interactions within the code that are relevant. Part of it is a way of "slow debugging", of not jumping to conclusions when you encounter unexpected behaviour but drilling down into what made the behaviour surprising, and revising your mental model of the program.

Put like that it's clear that to "simply write unit tests", for instance to check a box in a process model, cannot possibly give you the same benefits as practicing the above interrelated set of skills. But it's also clear that it requires more involved guidance than "just write the test first". You can pick up a lot of it on your own, to be sure, just like many people can learn (say) guitar on their own and get all sorts of nuance in technique from focused practice.

But you have to love doing it, and that's not something easily picked up in academic studies.

It's normal to experience emotions related to what happens at work. It's called "being human". And dealing with emotions - putting words on them, accepting them and moving on - is a key skill and a part of growing up.

What varies, in my experience, is whether and how much it is acceptable to discuss (and thus process) these emotions in the workplace itself. Being able to say "I'm sad / angry / joyful about X" makes a world of difference.

Once I became aware of that I started being able to remedy it. To start with I actively sought and encouraged discussions of the emotional components of whatever work I was a part of. Retrospectives were a great way of having a structured framework for these discussions (as opposed to giving the impression that I wanted to psychoanalyze my colleagues or vice versa).

After a while I noticed, too, that management in some places actively preferred the dehumanizing effect of making emotions undiscussable, because it afforded easier control over people. I started avoiding these places and selecting jobs that accepted and expected me to behave as a human adult.

It's quite common, and known as "plagiarism". It will usually get people discredited quite thoroughly.

A fantastic book on the history of the search for gravitational waves: "Gravity's Shadow" by Harry Collins.