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

'A philosophy of software design' by John Ousterhout, great book which provides good understanding of what complexity in software means. Very concrete and short.

Yes, this book is excellent. And it's an antidote to some common advice that really isn't very good.

Yeah I feel the same. Its more of a philosophy. Its good to learn but hard to implement in this fast pace development process. It make sense if you have big team which job is to assess the quality of the code

I liked the books emphasis on "interface" vs "implementation", and how this affects complexity.

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

That sounds like DRY, don’t repeat yourself. Taken to another level I try to think of this as instruction elimination. Where can I eliminate the most instructions, still pass all my tests, and then compare execution speeds?

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.

The Pragmatic Programmer - I read this book when I was programming professionally for maybe 5 or so years, so I already had my basics covered, but reading this book really expanded my horizons on what it means to create software profesionally. I read, maybe, 100 books about programming since and before then, but no other book changed my thinking that much like this one.

Totally agree. If I had only one book to give new engineers, it'd be this one.

The Pragmatic programmer is actually a short summaries of all those top 10 books :D

I wrote it about here : https://burhanrashid52.com/the-pragmatic-programmer/

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

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

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

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

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

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.

> But this is not TDD.

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.

For me TDD really helps when I am trying build business logic but its hard to follow when you want to test the UI logic Because the UI test work behave differently than the actual application

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

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

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

i would say cleancode is a counter example as most devs that read and like it just go through a phase of being unbearable and confused before figuring out their error and giving up. my absolute mind changer book was joe Armstrong's programming for a concurrent world, even without wanting to go into beam development this will change the perspective of devs in a profound and fruitful way.

Agreed on Clean Code. I remember nothing practical from that book. Its principal value is that it looks nice on my shelf.

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.

For me, two books that changed how I thought about software were (and I may date myself here):

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

On a similar note, the book crafting interpreters on build programming language changed my perspective on the day-to-day code I read.

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.

I enjoyed this one too. I remember reading about the NOP sled and it blowing my mind

Still have this book from over a decade ago. Never read it. Is it still relevant?

K&R C has to be my pick. I love it because it not only teaches you C and how to implement some of the standard functions but also there's enough pearls of wisdom in there to really help you improve as a programmer.

What is K&R ?

https://www.amazon.ca/Programming-Language-2nd-Brian-Kernigh...

In another thread I mentioned Peopleware: productive projects and teams. Even the best programming book in the universe won’t help if the environment, leadership and team don’t support your efforts. this book is about that and how to give creative knowledge workers the environment and tools they need and then get out of their way and keep others out of their way as well.

A great read whether you’re wearing a programmer hat or a manager hat.

Yeah…half of approaches the book talk about is inperson offices which is changing is right now.

And the mythical man month was written in the age of mainframes, yet remains relevant.

I would not say the books of Diomidis Spinellis are timeless or that will change your life as Engineer. But always though they do not deserve the low ratings, and that as an author, he is very unfairly judged. So I am adding these three to this thread.

"Code Reading: Open Source Perspective" - https://www.goodreads.com/book/show/529511.Code_Reading

"Code Quality: The Open Source Perspective" - https://www.goodreads.com/book/show/169414.Code_Quality

"Effective Debugging: 66 Specific Ways to Debug Software and Systems" - https://www.goodreads.com/book/show/26720867-effective-debug...

I really enjoyed Tragic Design.

https://www.amazon.com/Tragic-Design-Impact-Bad-Product/dp/1...

There are two books which I keep coming back to learn from:

* Structure and Interpretation of Computer Programs: SICP changed the way I view programming. It's an excellent intro to the mindset of solving problems with code and how to iteratively build up a software design. You need to be comfortable with Scheme, though, in order to get the most out of the book.

* The Mythical Man-Month: Not strictly about programming but more on how to succeed with software projects. Hence, The Mythical Man-Month is more about people than code, which is why it has aged so well: people is a fairly stable construct.

'Expert C Programming: Deep C Secrets' by Peter van der Linden

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

Always heard about this book so I got the anniversary edition. Amazing book.

How is it different from peopleware ? To me its feel the same.

Agreed, mythical man month should be on all software book lists.

I would also include: Design Patterns: Elements of Reusable Object-Oriented Software

I didn’t read mythical man month because it felt similar to peopleware.

The classic design pattern book is very jargon heavy. Not for someone who is just starting out.

Not a book, but an article: Herb Sutter's "What's in a Class?" completely changed the way i thought about OO programming and still holds up today.

<http://www.gotw.ca/publications/mill02.htm>

PS: plus anything by C++ guru Scott Meyers.

"Programming: Principles and Practice Using C++" by Bjarne Stroustrup, the creator of C++.

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’ve heard about this book but didn’t read because I didn’t got chance to work on a C++ project.

I forgot to mention my answered tweet. So here it is : https://twitter.com/burhanrashid52/status/169351610891202580...

It's more about engineering management but 'Accelerate: Building and Scaling High Performing Technology Organizations' by Nicole Forsgren (Github VP), Jez Humble and Gene Kim is a must-read.

Related thread:

If you could only have one programming book on bookshelf what would it be?

https://news.ycombinator.com/item?id=38229464

The Linux Command Line

by William Shotts

Glad to see this mentioned. Still keep it on my desk. This book strikes the perfect balance between reference and introductory reading.

'Elements of Programming' by Stepanov and McJones

'Software Fundamentals' by Hoffman and Weiss,

'Writing Solid Code' by Maguire,

'Code Complete' by McConnell

Wow!! All this new to me. Never heard of them. Will check that out.

Code Complete is one of the best books for beginners to improve their general, non-language-specific skills, IMO, though it does have language snippets as examples, and even though it is somewhat dated. The principles in it are timeless, though.

I have read both the 1st and 2nd Editions, many years ago. IMO Edn. 1 is better.

Two by Nicklaus Wirth: Algorithms + Data Structures = Programs Project Oberon: The Design of an Operating System and Compiler

Unit Testing Principles, Practices, and Patterns

by Vladimir Khorikov

Nice!! I read Working effectively with Unit Test by Jay Field. Very short and insightful read. DAMP vs DRY was eye opener for me.

Wrote about it here : https://burhanrashid52.com/working-effectively-with-unit-tes...

"The Little LISPer", by Daniel Friedman, brought FP home for me.

Can you edit and reformat the text by adding breaks?

For me, "Hackers and Painters," by far.

@burhanrashid52

In general, we should not be using HN with LLM copy. However, I can suggest a technique for you to help you accelerate your effort towards a book and the "hard part" of getting a professional editor and publisher.

Using GPT-4, which has a synthesized 'understanding' from reading endless reviews of such well known material ...

1. Provide the list of books as recapped in the comments below, with the prompt:

Create a list of the top 3 principles or takeaways from each of the 13 books. List only the principles, not the books they are from.

You should get about 35 - 38 principles in a list numbered 1 - 36 or so.

2. Group them with a prompt like:

What 5 overall themes can these 38 principles be combined into?

You should get five buckets with an explanation of each bucket.

3. If anything is misbucketed, tell it the bucket changes you want, for example:

Version Control should come with Testing and Maintenance. Data Management and Scalability go together better.

4. Now put the 40 principles into the buckets:

Using these 5 themes and their explanations as sections and intros, organize the relevant items from the 36 principles as bullets under each of the 5 themes.

You should end up with 5 solid book sections and enough bullets you can see how to break into 2 - 3 chapters per section of 2 - 3 good topics each.

(I'm not copy pasting an output here, but results from the prompt recipe above pass a first draft sniff test.)

5. Pick two or three of those you, personally, can write about in your own voice not using GPT-4, and without referencing source material, and write a first draft. Do not use an LLM.

The point here is to let your own view and originality and voice shine, using the material you are most confident about, to "sell" an editor that you are expert enough for the whole book

6. With this outline and sample short chapters, submit a book proposal to publishers, who, if accepting, will have early feedback that will help you have less rework, and will also have an signing bonus and/or royalties advance for you to support you while you write.

It's not an LLM copy. I wrote it all myself. Most of the book I've already summarized here: https://burhanrashid52.com/reading

Thanks for the advice, will definitely try it out.

I have used the same technique to summarize survey results and to look for new books to possibly read.

It works well for the most part. GPT with its compression leaves out all the stories and metaphors that make the content easier to remember and relate to.

all i can say is ... no

i would be interested in stopping you writing your book - i really do not think you have any idea about software development

Thanks

K&R

Did you get this booklist from ChatGPT?

I don't think so as he got at least one title wrong: Head First Design Principles should be Head First Design Patterns.

I got that book when it came out, and I quite enjoyed it. Their presentation of material was quite different at the time.

Right, because ChatGPT is never wrong.

It is very often wrong, but (at least ChatGPT4) outputs proper names correctly. Principles/Patters may seem similar for someone who hasn't been around long enough to see the whole hype cycle of "Gang of Four" seminal work.

No, I did not. Making grammar mistakes is blessing now a days :)