6 ms·

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 (D

by dpflan 3y ago

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 Design Principles (Terminology and concepts for maintainable and extendable design) 6. Algorithms to Live By (Algorithms are fundamental ideas before we write any code) 7. Git Pro (Software cannot run without a Version Control System (VCS). We use it every minute of our working day) 8. Your Code as a Crime Scene (Finding problems in the code using code history) 9. Data-Intensive Applications (Databases are everywhere) 10. Software Engineering at Google (Addressing the biggest scaling problems) Honorable Mentions: 1. Clean Code (Writing code that is easy to understand by other developers) 2. The Soft Skills (Coding alone is not enough to be a great software engineer) 3. Peopleware (Managing software teams).

nephrenka 3y ago
> 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-scene-second-edition/ https://pragprog.com/titles/atcrime2/your-code-as-a-crime-sc...
dpflan 3y ago
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 https://news.ycombinator.com/item?id=38229464
tester756 3y ago
>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.
- voiceofunreason 3y ago
  > 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.
  - tester756 3y ago
    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?
- voiceofunreason 3y ago
  > 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.
- sam_bishop 3y ago
  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.)
  - tester756 3y ago

by dpflan 3y ago

nephrenka 3y ago

> 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-scene-second-edition/ https://pragprog.com/titles/atcrime2/your-code-as-a-crime-sc...

dpflan 3y ago

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 https://news.ycombinator.com/item?id=38229464

tester756 3y ago

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

voiceofunreason 3y ago
> 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.
- tester756 3y ago
  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?
voiceofunreason 3y ago
> 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.
sam_bishop 3y ago
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.)
- tester756 3y ago