21–30 of 72 posts
A great read whether you’re wearing a programmer hat or a manager hat.
I learned programming first time from this book and I think I'm so lucky that I've done it. The book is about philosophy and the mindset of programming more than introducing some tools or techniques, so we can consider it as "timeless".
I would also include: Design Patterns: Elements of Reusable Object-Oriented Software
Hacking: The Art of Exploitation (ISBN 1-59327-007-0), Jon Erickson Really helped me bridge the gap with low-level, debugging, and C approx half a lifetime ago.
_The Mythical Man-Month_ by Fred Brooks is a short, easy read and remains packed full of timeless truths. His separate essay “No Silver Bullet” is included as an appendix and clarifies which problems to attack. A combination of improvements in tools, languages, and practices over the decades since have led to dramatic improvements since that essay, but, still, the problems of understanding and communication remain.
The Linux Command Line by William Shotts
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…
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.)