Well I do TDD around 85% of the time and I'm doing pretty well financially as a dev. Sometimes it isn't possible to do TDD, like when I'm iterating on a data science algorithm or exploring data and relationships before settling on a final approach. But you're right, most devs I know don't do it, though I've noticed the ones that do generally make more.
> I’ve noticed the ones that do generally make more.
The market may be rewarding the TDD skill, it makes sense. But consider that causality makes sense the other way around too. Anyone with the patience, eye for detail, and organizational skills demanded by TDD could be just an above-average programmer.
Personally I like a “don’t forget the tests” approach for larger units of business logic, but I’m against exhaustive micro-test suites that just turn into bespoke, buggy, and useless-at-compile-time type systems.
The top 50% are capable of actually doing TDD? I don’t see why that’s impossible, especially if they are the ones implementing it, not just pushing tickets along within it.
And I don’t really follow TDD practices myself, so this would say nothing about me.
Careful with this reasoning. It could be that those who insist on TDD are simply the loudest or most confident or whatever, and therefore are more often in a position to advance themselves. "Their stuff works better" isn't necessarily the link between "TDD" and "make more".
Interesting. You're defending and advocating for TDD, and you use it 85% of the time. I've used TDD as well, and I notice it tends to work very well for certain types of workflows. Otherwise, I write a little code, test a little code, back and forth. Almost everyone does this (you write a method, you tend to write a little test to see if it does what it's supposed to). To get high test coverage, you just save those little tests that you naturally write anyway. It's a good way to get high testing coverage without imposing an odd-feeling methodology into what should be a creative workflow.
When the big "TDD is dead" debate hit the scene, I felt that DHH and the detractors won that debate big time - even though I use TDD and consider it to be a valuable tool.
Why would I think this - after all, if I like TDD and often employ it, why would I agree that the people who claim it is "dead" have won?
Probably because the debate had become relatively extreme:
"If I am right… If TDD is as significant to software as hand-washing was to medicine and is instrumental in pulling us back from the brink of that looming catastrophe, then Kent Beck will be hailed a hero, and TDD will carry the full weight of professionalism. After that, those who refuse to practice TDD will be excused from the ranks of professional programmers. It would not surprise me if, one day, TDD had the force of law behind it."
Whoah! And keep in mind, people were acting on this. I read a blog (sorry no cite) from a highly regarded developer who worked as a contractor to restructure software dev teams, and he came flat out and said that if people don't adopt TDD, they won't be employed for much longer wherever he works. I got the feeling that even questioning it would be considered grounds for "no hire".
That mentality is what I think is "dead" - and this is evidenced in the fact that you and I (who do quite a bit of TDD) acknowledge that it is not something we always do and that it isn't always possible or desirable. I got in wicked arguments about this at work, and I'm almost certain I was dropped from consideration for jobs during interviews where I argued the now more moderate position which, ironically, makes me one of TDD's defenders in 2020!.
Absolutely, but I still prefer the interfaces that come out of doing proper TDD. I minimize the use of mocks and try to pull in as much of the infrastructure as possible. I'm pragmatic though. I'll use fakeredis in tests instead of actual redis so the tests can run concurrently without quirks.
It's hard to communicate as a developer at times. We're all learning different things at different times and taking things to an extreme can cause bad outcomes for the rest of the team. One of the reasons I try to be accurate during online discussions. "I do TDD 85% of the time" is a better thing to add to the conversation than "I do TDD" since it gives people the idea of nuance in software development methods.
Curious - did you hold this opinion around 5-10 years ago, and did you voice it to any TDD advocates at the time? My experience was that a statement like this (which I consider immensely reasonable) could kick off really severe arguments, and could get you no-hired in interviews.
There may have been a bit of a Motte-and-Bailey argument going on, where TDD advocates would retreat to the value of tests when defending TDD, and then go back to insisting on TDD once the coast was clear.
There have been several phone screens in my life in which as soon as we started speaking about TDD and/or agile, they completely lost interest.
But as far as I'm concerned that's a good thing. I write tests where it makes sense, and I can think of 1 project where I eventually regretted the decision not to write tests (before or after), but even then it didn't really hurt it just would have been a lot less scary with a good suite of tests around some specific functionality (related to pulling emails, doing the wrong thing there could mean permanently losing emails without processing).
