Saw a post flit across my timeline which intimated that TDD will help you write correct code, and a linter clear code.

Naw.

Writing tests before writing runtime code simply means your code will pass the tests you already wrote. Whether or not the code is "correct" is entirely a separate matter (and you can write "correct" code before you write any tests).

Similarly, code can be any shade between clear and unclear…and linters rarely are a magic solution and sometimes will cause the problem!

I understand some people find great comfort in the rigidity and discipline which comes with strictly adhering to semi-automatable norms when programming. I've always been quite on the other end of the spectrum. To me, coding is much less like solving a math problem and much more like playing jazz music or composing an essay. Will I sometimes TDD? Sure. Other times, that would be an utter waste of my time. It's just a tool. It's not "the thing".
@jaredwhite Oddly enough, I come from a mathematical/scientific background and my approach (which is much the same as yours) was drilled into me at university - you can't do anything innovative by following the same predefined steps each time. I think software is just pragmatic art.
@jaredwhite I agree 100% with your take and practice the same routine. Not all code deserves TDD. But a must for important business logic, reusable services/components, public apis…
I do like TDD but I’ve seen a lot of bad tests that don’t do anything, just check boxes…

@hacrods Sure, if you have a bucket o' logic that has been pretty well spec'd out in advance and you have a decent idea what the expectations are for how it should work in the end, then by all means, TDD away!

(Also I agree, the "just check boxes" sort of tests can be problematic in and of themselves…)

@jaredwhite if you have a large enough team, by all means you should aim to have high test coverage. IMHO.
In that case you will have enough developer time to invest in it, even though you may later on change some of that logic and the tests.
But for small teams, too much TDD is a big waste of time which often will give you nothing (so lose-lose situation)
@jaredwhite Yes! 💯 So much this. I love the jazz analogy.

Given strictly speaking TDD would mean writing tests first, I guess it’s worth mentioning not following TDD doesn’t mean not having a good test coverage?

Sure, sometimes I write test first, while other times I go for implementing code first and write tests later. Writing tests help to find use cases and scenarios I didn’t think about when implementing the logic.

@jaredwhite Love the post. :)