Ask HN: Top 10 Timeless Software Books That ChangedLife as Software Engineer?
Here are mine, in order of how a developer starts their journey, from basic to scaling problems:
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).
Also, I am planning to write a short book summarizing all the important points from these above books. If you are interested in getting one or want to be part of an early reader, please email me at burhanrashid5253@gmail.com.
71 comments
[ 3.9 ms ] story [ 149 ms ] threadI wrote it about here : https://burhanrashid52.com/the-pragmatic-programmer/
by Vladimir Khorikov
Wrote about it here : https://burhanrashid52.com/working-effectively-with-unit-tes...
by William Shotts
https://www.amazon.com/Tragic-Design-Impact-Bad-Product/dp/1...
Really helped me bridge the gap with low-level, debugging, and C approx half a lifetime ago.
But one tidbit I did like from the book was along the lines of "if every use case involves the same action, it would be simpler to incorporate that action". (e.g. Something like if ".delete()" were to fail if the file didn't exist, and if every invocation would be like "if .exists() { .delete() }", then it'd be simpler to have a method without the "fail if file didn't exist" requirement).
Instruction elimination and DRY are basically the same things in practice but the former produces a more aggressive and utility focused mindset. I find when I think about large applications with instruction elimination mindset I am constantly churning on refactoring as requirements increase but the code size grows so very slowly that there is less to maintain and test automation continues to be measured between less than 7 seconds and up to 2 minutes depending upon the scenario and number of machines involved.
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).
If you could only have one programming book on bookshelf what would it be?
https://news.ycombinator.com/item?id=38229464
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.
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.)
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.
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.
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.
Do you have any example where going red-green found issues when writing new code?
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.
There's a brand new 2nd edition on its way: https://pragprog.com/titles/atcrime2/your-code-as-a-crime-sc...
'Software Fundamentals' by Hoffman and Weiss,
'Writing Solid Code' by Maguire,
'Code Complete' by McConnell
I have read both the 1st and 2nd Editions, many years ago. IMO Edn. 1 is better.
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".
Watching Bob Martin's talks, he just likes ranting about computers and doesn't give actionable advice. However, he was one of the first "tech" authors I was exposed to, so I guess the the book itself is good for marketing. Maybe it's accessible enough for beginners. But now the book is certainly worthless as a reference or refresher to me.
I would also include: Design Patterns: Elements of Reusable Object-Oriented Software
The classic design pattern book is very jargon heavy. Not for someone who is just starting out.
i would be interested in stopping you writing your book - i really do not think you have any idea about software development
If you could only have one programming book on bookshelf what would it be?
https://news.ycombinator.com/item?id=38229464
1. Advanced Programming in the UNIX Environment[0]
This changed writing software from being about the code I was writing to being about the underlying systems my code was interacting with. My favorite little feature I learned about was the ability to pass open filehandles between processes (not threads, but processes), which I later used for open connection caching in Usenet systems.
2. Object Oriented Perl[1]
The mind-bending part of this book for me was when Conway explains about using structures other than hashes (dicts) as Perl objects. Arrays were interesting, scalars slightly more so, but then functions ... as objects. This one chapter brought clarity to functional programming that I never got from any other explanation.
All the other books listed here are on the list two, but these were two books about specific mechanics of software development that were worth so much more outside of their respective languages.
(edited to add links)
[0] https://www.pearson.com/store/p/advanced-programming-in-the-... [1] https://www.manning.com/books/object-oriented-perl
<http://www.gotw.ca/publications/mill02.htm>
PS: plus anything by C++ guru Scott Meyers.