cenny

Great resource!

I agree TDD is a good way to learn a new language.

One of my favorite books Exercises for Programmers (https://www.programmingbooks.dev/extra/#exercises-for-progra...) promotes this approach as well.

This is a great book and a strong recommend from me. It has earned a spot on my reading list: https://www.programmingbooks.dev

`Explain the Cloud Like I’m 10` and `Exercises for Programmers` are two great books for beginners. I talk more about this exact subject here: https://www.programmingbooks.dev/articles/beginner

Good list and thanks for sharing. I have my own list (https://www.programmingbooks.dev) with some overlap.

I disagree with the usage of the wording “should read” in the title. Reading programming books is great and a great way to learn but implying that everyone should read these books can be counterproductive as it might turn people of from reading as it can be interpreted that one is not a good engineer if one hasn’t read them.

> Instead the pyramid says we should write a lot of unit tests. This leads to an inside out approach testing the structure of the system rather its behaviour.

No it does not. Unit tests should test behavior.

> Only use mocks for truly external systems (e.g. mail service). The database should be part of the tests. Do not stub it.

First, mocks and stubs are not the same thing.

Secondly, stub fragile dependencies in unit tests is a good rule of thumb if you want easy, fast and non-erratic tests.

> Never change your code without having a red test. This is pretty common practice in TDD.

No, In TDD we change our code all the time without a red test, we call it refactoring and we only do that when the test is green.

There are so many misunderstandings in testing and TDD. I wished more people would read Kent Becks book [Test-Driven Development: by example](https://www.programmingbooks.dev/#test-driven-development) and then the amazing book by Gerard Meszaros [XUnit Test Patterns](https://www.programmingbooks.dev/#xunit-test-patterns).

In the end I'm just happy if more people practice TDD and understand it's a skill to learn like everything else and not a silver bullet.

The three books that I have appreciated the most when it comes to computer science must be:

- Code The Hidden Language of Computer Hardware and Software (https://www.programmingbooks.dev/#code)

- Grokking Algorithms (https://www.programmingbooks.dev/#grokking-algorithms)

- The Little Schemer (https://www.programmingbooks.dev/#the-little-schemer)

These two books I really found interesting as well:

- Nine Algorithms That Changed the Future (https://www.programmingbooks.dev/extra/#nine-algorithms-that...)

- Good Math (https://www.programmingbooks.dev/extra/#good-math)

I'm no C++ expert. But Wouldn't a private constructor and a static method that returns nil if input is bad fix this problem?

Joshua Kerievsky talks a bout this problem in his book [Refactoring to patterns](https://www.programmingbooks.dev/#refactoring-to-patterns), specifically the refactoring "Replace Constructors with Creation Methods"

That is maybe beside the point of the articles argument he is making about C++ being bloated and hard to use and read ¯\_(ツ)_/¯

Thanks for the feedback and nice words!

I will look into “A Common Sense Guide to Data Structure and Algorithm” and see if I agree with you.

But yes, little schemer is so good, wished I read it earlier than I did.

What kind of habits do they advocate that interfere with writing good code?

I would love to hear more about this opinion.

The link was supposed to go to an article on the site (https://www.programmingbooks.dev/articles/book_is_wrong/)