And there is a current post on the frontpage about if you could have only 1 book:

If you could only have one programming book on bookshelf what would it be?

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

>4. Test-Driven Development (TDD) (Once you’ve learned all the above, you always start writing tests first)

I've seen like bilion discussions about TDD and I still dont understand why is it so overhyped.

Additionally it sucks that for some people you either do TDD or dont write tests at all (what the f...., indeed)

This whole red-green step in TDD makes complete no sense when you're writing new code.

The only value provided by TDD when writing new code is that you're forced to think from caller/user perspective, so it makes your API design better, that's it.

I don't use the proscribed TDD process very often, but I use the TDD mindset all the time to great effect.

Listing out the tests you're going to write before you write the code (even mentally) can be considered a continuation of the requirements-gathering process. And thinking about how you're going to test your code before you write it will, in my experience, improve the design. (Particularly, it seems to encourage the single-responsibility principle, as code that's doing too much or combining layers of abstraction is really hard to test.)

>Listing out the tests you're going to write before you write the code (even mentally) can be considered a continuation of the requirements-gathering process.

But this is not TDD.

I've worked in HW industry where cost of bugs is high and we analyzed specs during brainstorming session as 3-5 ppl and brainstormed test cases that we want to test.

It worked well because this way we we're finding way more things to test than when doing it alone.

But still, this is not TDD. We weren't doing TDD.

>(Particularly, it seems to encourage the single-responsibility principle, as code that's doing too much or combining layers of abstraction is really hard to test.)

Whether your code is easily testable will be challenged by writing tests regardless of the moment of writing test - before or after writing impl.

So no benefit from TDD over non-TDD approach.

> But this is not TDD.

That's true. Did you miss the part where I mentioned the "TDD process" versus the "TDD mindset"?

> Whether your code is easily testable will be challenged by writing tests regardless of the moment of writing test - before or after writing impl.

I don't want to derail the conversation, but when I'm working on projects alone then my test coverage is 100%. (Line and branch coverage.) But surely that slows me down, right? And I must have a million test cases? No, quite the opposite actually. Writing code that way is just a skill though, the same as juggling, that becomes easy with enough practice. (Along with the right practices and tools.) However, I don't aim for 100% (or even a particularly high percentage, to be honest) when I'm working on projects with other people, because the only way it's possible is if the code was designed for it from the get-go.

I encourage junior developers to learn and try to use TDD for a while because it can be useful sometimes and improve the way they write code. But I would never require them to do it.

> I've seen like bilion discussions about TDD and I still dont understand why is it so overhyped.

My guess: because it picked up a lot of momentum from the OO "patterns" community, and that gave it a lot of immediate reach and credibility.

Beck and Cunningham already had an audience of their own, and TDD also promoted Martin Fowler's ideas (pulling in his audience), and Robert Martin jumped aboard early as well (pulling in his audience).

The cynic in me notes that the Smalltalk community needed something to do, as it had by then become clear that Java was going to win that market.

> This whole red-green step in TDD makes complete no sense when you're writing new code.

Only viewed in isolation - the point of red-green is test calibration: be certain that your new experiment is actually measuring the thing that you think it is measuring.

Red-green isn't the only way to achieve this, of course, but it is a smooth way to achieve this.

The only scenario I can think of is some crazy programming language / unstable compiler where such a thing would be needed when writing new code.

Do you have any example where going red-green found issues when writing new code?

For me TDD really helps when I am trying build business logic but its hard to follow when you want to test the UI logic Because the UI test work behave differently than the actual application

> 8. Your Code as a Crime Scene (Finding problems in the code using code history)

There's a brand new 2nd edition on its way: https://pragprog.com/titles/atcrime2/your-code-as-a-crime-sc...