Live data from Hacker News

Ask HN: Top 10 Timeless Software Books That ChangedLife as Software Engineer?

news.ycombinator.com

71–72 of 72 posts

Re: Ask HN: Top 10 Timeless Software Books That ChangedLife as Software Engineer?

#71
post #14

Thanks for the list, here it is again: 1. Code: The Hidden Language of Computers (Pure Basic: Starting with Binary) 2. Working Effectively with Legacy Code (Dealing with an ugly codebase) 3. Refactoring Improve the design of the existing codebase (Making changes safely without breaking the code) 4. Test-Driven Development (TDD) (Once you’ve learned all the above, you always start writing tests first) 5. Head First De…

>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 p…

> 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.

Re: Ask HN: Top 10 Timeless Software Books That ChangedLife as Software Engineer?

#72

Earlier quoted context omitted.

>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 p…

> 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?

Post reply on HN