Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What books should I read to improve as a software engineer?
156 points by hopa 41 days ago | hide | past | favorite | 123 comments
I'm a recent grad looking to keep improving. I've read Clean Code, Game Programming Patterns, and Architecture Patterns with Python, and I feel I learned / improved a lot from each of them. I was looking at Coding Horror's book recommendation list: https://blog.codinghorror.com/recommended-reading-for-developers/ but all those books seem very out of date. Any suggestions for best books for software engineers in 2024?



"A Philosophy of Software Design" by Stanford's John Ousterhout is excellent.

It is quite concise (about 190 pages), but in my opinion, it includes all the essential information that the other books in that category would teach you. It leaves out a lot of cruft that over the years turned out to be non-issues (code styling, problems that come with object oriented programming, etc.) but occasionally - when the topic is popular and widespread (e.g. Uncle Bob advice) - addresses them as alternative opinions. It was first published in 2018 and is therefore not in the out-of-date category.

So I would recommend it as essential read, hands down.

If you want something a bit more elaborate: "The Pragmatic Programmer" has a 20th Anniversary Edition. It is a timeless classic, worth reading at any rate.

That being said, I wish there was a single consistent resource[1] that summarizes truly modern software design philosophy in the sense that it leaves the object orientation inspired ideas behind that did not turn out to be useful and focusses on typed functional programming. Maybe with examples in Typescript and Rust.

[1] Possibly a book, but not necessarily. For me it would be important that it presents a consistent opinion, so it should be from a single author or small group of authors. The information I have in mind is mostly there, but spread out over many blog posts from people with slightly different takes and ideas about them. The overwhelming majority of recommendations in this thread are from authors I'd consider part of the founding generation. I'd love to read about software design from the perspective of a younger generation.


I went on a long email back and forth with the author because this was the one book that opened my eyes so much that I did't know why the Ruby community (of which I was a part of then, but am no longer) would break so many of the principles of the book.

Maybe the only book that has actual made me a better programmer that I can objectively measure.


Would you mind clarifying which one you found so helpful? The parent commenter mentioned two books


You sort of have to marinate yourself in the ideas of the book. But the big one is that you should have a very limited API. And each API function should do a lot of things. So a very narrow set of deep APIs make for the best programs. The other thing was indirection. Try avoiding it as much as possible. Languages which allow easy access to functions or lambdas or blocks being pass around, usually end up with 4 - 5 levels of function calls to get anything done. That makes things really complected together and makes it hard to reason about later.


and which book are you talking about?


Deep APIs were mentioned in "A Philosophy of Software Design" (John Ousterhout)


A Philosophy of Software Design - John Ousterhout


Can you say more about how the ruby community is breaking these principles? Was that part of the reason you left the community?


So around the TDD phase of Rails and Ruby, there was this huge push to make methods 5 lines or really short and dependency inject everything. It would make changes incredible hard to make because which the open closed principle talks about how things like this should be easy to change, you end up with a lot of subtle bugs because your individual dependencies drift from each other. I think the Ruby community has gotten much better now with more experience but ya that time it was crazy. And Ruby allows you to really take the metaprogramming and block passing madness to the next level.

I didn't leave the community because of it. I left it because Ruby was slow as molasses, dynamic typing is a failed experiment (imo) and people would love magic and be proud of it. Which meant systems would break in production more times than I could take and I have done so many on call rotations because someone thought some magic was a fun way of doing it.

For personal projects I used Steel Bank Common Lisp because there the dynamic nature of the language actually has benefits such as programming through the REPL which is much more reliable than typing dynamic code in an editor to build programs.

Once I had to hire people I moved to Go but then again moved to Rust because I want to write programs which do not break, is fast as possible and doesn't take my users' memory and cpu for granted. Who am I to burn their electric bill or data plan while delivering broken buggy software to them. Plus I cannot stand null pointer exceptions and Go due to their ideological drive of remaining "simple" has null pointer exceptions in 2024.

Also the other meta thing I realized was because Rust is harder to get into, the discourse, libraries, tutorials, community is much higher quality compared to anything else I have seen so far so I really enjoy it. Plus Rust has some really cool things like high level maps and functional code while them compiling down to the same Assembly as for loops and other such zero cost abstractions that I like.


Funny, I spent the last decade working in a strongly typed natively compiled language (OCaml) and for fun I’m venturing into Ruby more and more, so kinda opposite of what you did :)

I’d agree that I wouldn’t like to support a large Ruby codebase commercially but in team of 1-4 devs and codebase not much larger than 10k lines it’s very productive (numbers pulled from thin air ofc).


> That being said, I wish there was a single consistent resource[1] that summarizes truly modern software design philosophy in the sense that it leaves the object orientation inspired ideas behind that did not turn out to be useful and focusses on typed functional programming. Maybe with examples in Typescript and Rust.

Not Rust or TS, but i found Java to Kotlin a decent book which provides refactoring of java OOP to more functional patterns. One of the authors Nat Pryce was big into OOP design and was also a co-author of famous book Growing Object Oriented Software by Tests.


If you want something a bit more elaborate: "The Pragmatic Programmer" has a 20th Anniversary Edition. It is a timeless classic, worth reading at any rate.

I haven't read the original The Pragmatic Programmer, but picked up the 20th Anniversary Edition. Maybe it's because the original was so influential, but I didn't enjoy the 20th Anniversary Edition at all, it just full of boring platitudes.


I read A philosophy of.. and I might as well be reading Philosophy because I didn't understand what the book was saying


I’ll have two recommendations.

1. A Philosophy of Software Design is very good. Not the whole of it but it’s short and to the point.

2. Fiction, as diverse as possible. I apologise for making assumptions but many software engineers are secretly lacking in understanding other people, what kind of of life experiences that have, how they think about the world, what is important for them. If you work with people it is going to be useful.

Also, it’ll enrich your life and you’ll have more to talk about during coffee breaks :)


I'll second the recommendation of fiction (I love the classics) and add a recommendation for reading philosophy and specifically the history of philosophy. Learning how our frame thinking evolved from the time of the Greeks to the middle ages to more modern times has been nothing short of illuminating for me personally. I don't think you need to read the original works or the really academic stuff (you can if you want to) but having a feel of how our thinking got to be is really useful.


Totally agree about fiction. Hadley Wickham's textbooks were influential in my path to become a data scientist. The writing is so good. I follow him on Goodreads and he is a voracious fiction reader.


Point 2. is interesting. Is it your personal experience or you have some sources to explore that topic?


Personal POV:

I mostly read Fantasy books and a little bit of SF, but the main points I would say is better visualization. Reading textbooks gives you understanding, but being able to reconstruct scenes and characters just from a few lines is a nice plus. When reading story from a ticket, it's become much easier to visualize a concrete use case. Also empathy building. Manuals and documentation are very dry and text is more constrained bandwidth-wise than visual interactions. Reading fiction can help you interact better through text emotionally. And we respond better to stories than logical arguments.`


Do you mean visualising a mental imagery? Because I wonder if I never could enjoy fiction and anything with long descriptions of a scene or what something looks like because I couldn't see the image and other people do? E.g. I might have aphantasia?

I like the idea of learning about human psychology though.


You might indeed. I do as well, and the long scenery descriptions are basically fluff to me, adding nothing to the experience. That said, I quite enjoy fiction, so that must be something else.


Indeed. Do DnD style tabletops with your dev team mates. Seriously. It definitely enables you to know how they operate.

And in general, it also enables you to understand the meaning of some writing for and from others.

Boosting its creativity is a nice bonus.


Am not the OP, however, I have similar observations too. I noted that people who read fiction often handle various life's situations better. My hypothesis is that this would be because they get broader exposure to life's situations than what non-fiction books deliver in practice.

I wish there were a lot more non-fiction books dealing with common and uncommon life's situations, which step out of the theory towards what actually happens in practice.


Could you give some more specific examples of such situations?


Love and relationships, rejection, failures, etc. When I was in middle to high school, I had no good understanding on how to handle these. Later too, have struggled with some situations. There have been situations that were nowhere talked about in any coursework and are somewhat rare that many people do not have experience with them. Movies sometimes talk about various situations, however, deal lesser with practical situations. I found that a few people around who understood these better and were known to be more mature had all been reading fiction books from middle school.


Personal experience. I’ve come back to reading fiction after a long break and noticed a difference.


It's probably useful to un-read Clean Code, though I don't really have a recommendation for a good replacement. The replacement is something like "Make a lot of mistakes and develop good taste based on your experience."

If you're interested in performance, you can read https://algorithmica.org/ and https://people.freebsd.org/~lstewart/articles/cpumemory.pdf


I keep seeing this online. Why? Clean Code was instrumental in my improvement as an engineer.

Is there a reason why this is the opinion nowadays?


One of the problems I have with it is the advice comes down to unhelpful abstractions that tries to wave away mechanical empathy.

I spent years writing Ruby and found clean code OK, but preferred Sandi Metz’s writing. Then I started doing some Go and Bill Kennedy made me think about mechanical empathy more. Recently I’ve been diving back into my old haunt of C, particularly more modern C idioms and the C23 standard as I need very fine grained control for latency and memory efficiency reasons for the apps I’m writing (in a very different space to where I worked in Ruby). It’s kind of blown away a lot of the advice from clean code for me.

The thing you’re programming has a CPU with registers. There’s a stack. There’s a heap. The choices you make choose how those things are used by the language implementation you’re using. Languages and methods that try to pretend none of that is happening can lead to very inefficient code that makes everyone sad.

Yes, your code needs to be readable. It has to be maintainable, but the clean code way of doing things doesn’t seem to do that very well AND introduces patterns that can make it hard for compilers and interpreters to optimise.


This is a short read - https://overreacted.io/goodbye-clean-code/

But it captures it perfectly, a large number of engineers go from jr to intermediate with their new found tricks. Except they cling to these tricks like it’s law, they have upskilled in one direction while sacrificing the open minded pragmatism for dogmatism. They’ll argue with you about these things, it’s in a book how can you not adhere to it!!?

If you can onboard these lessons and still recognise the spots where it’s begging for some best practice but you should break the rule this time, then congrats you’re ahead of the curve, it takes most engineers a frustratingly long time to get pragmatic. If I had a penny for every awful DRY abstraction that became impossible to reason about, I’d have retired.


"Clean code", when not applied judiciously, tends to result in overly complex code with a lot of repetition. This may be desirable when very strict decoupling is needed in complex projects, but in many projects it makes things worse rather than better.


I suspect that one of the main reasons is that people read it and think they have to adopt all of it.

Personally I still recommend it to people but with the caveat that they need to think about what aspects from it they adopt and which don't make sense for them in their environment. E.g. if function calls are expensive in the language they use and its compiler doesn't optimize their code by inline the ones it can, then they probably don't want to break things down to the level that Clean Code recommends.


I also love Clean Code and think it unfairly gets a bad rap, but here's a great, sometimes hostile, conversation with the author that touches on the issues:

https://github.com/unclebob/cmuratori-discussion/blob/main/c...

The linked video is also a good watch.


Thank you for posting that!

Just for context, this was posted to Github by the author of Clean Code himself, Robert C. Martin, while exchanging messages with Casey Muratory [0]. They talk about performance, about testing, and maybe other stuff (I'm at less than half of it)

[0] of Handmade Hero fame, https://www.youtube.com/watch?v=A2dxjOjWHxQ


I think that some of the advice hasn't aged well into modern language features and computer power, similar to the GoF Design Patterns book. Rather than an entry level book, this would be better for a budding intermediate who can parse what is good and bad about it.

But, even then, other resources are better IMO. (Metz, Ousterhout, Kay, PragProg, language-specific design patterns books, etc.)

The experience of doing things wrong is valuable, but I think you also don't want to get quagmired there. It just depends on how voraciously/quickly you read and seek out better patterns.

(Also, elephant in the room, Uncle Bob has been very vocal and opinionated on the internet about various things and it hasn't endeared many to him because of it)


I think it depends. For me, I can see how it helps a brand new developer get a feel for code style.

That being said, some of the advice in the book is simply dated, some of it seems to break code down arbitrarily instead of on responsibility.

On top of this, you get people who pedantically follow it and don't let a team of experienced engineers develop a style that works for them it's really annoying and it can make the codebase a bitch to work on.

In the end, it should be a guide. And you should be thinking about what bits to take. But what ends up happening is "uncle Bob says...".


Because of clueless extremists.

They don't try to understand the spirit of rules, but blindly apply rules to the letter


I haven't read it, but based on the examples from the book in "Goodbye Clean Code", the author is one of those extremists.


https://qntm.org/clean


This isn't the general opinion. Clean code is great.

But sometimes, what you want to do is so complex. You'll want one big file with few methods and a lot of comments.

I think the "perception shift" happened together with public discussions of sqllite.

The tldr would be: just don't consider it a Bible ;)


algorithmica.org; only if you can read Russian, as the English version is WIP and the main version they work on is the Russian one.


The English version is a best-in-class English among those that are free.


I would split the books into two categories: those that improve the way you structure your code and deliver a software solution, and those that improve your technical understanding of the software platform and the computer you're using.

The first are books like Pragmatic Programmer, Mythical Man Month, Code Complete, Design Patterns, talks by Alan Kay on software systems and OOP, even Game Engine Architecture etc. A lot of the content there is distilled experience which is much faster to learn from a book than gain the hard way on the job.

The other books are practical deep dives. Here I would recommend a variety of books like Inside the Machine by Stokes, Computer Architecture by Hennessy, 21st Century C by Klemens, Crafting Interpreters by Nystrom, Compilers by Aho, Effective Java, Nature of Code by Shiffman, Ray Tracing Challenge by Buck, Hands on Hacking by Hickey, and others, depending on your interest and area of focus.


I split my library alongside the same line. One section to answer the following questions: Why should I do it, how should I do it, how should I not do it, how does it work,.. and the other section answer the following: What to do, what to use,... The first one helps decision and planning, the second is what you use.

So there's the philosophy of the craft which are mostly the core skills of software engineering (or engineering in general). Problem solving, project planning, resources planning, methodologies,... Then the various theories (computer science). Algorithms, Data Structures, Computer organization, Networking, Databases, Operating Systems,... And then the skills. Programming Languages, Libraries, Tools (editors, shells, build systems, debuggers, test runners). Being a good programmer involves being fairly knowledgeable in all three.


Why is Effective Java in the second group?


The Mythical Man-Month and The Design of Everyday Things are not out of date, even if older texts. The Pragmatic Programmer is also still worth a read and received an update since that list was created.

EDIT: An old book (also received an update) I'd add is The Psychology of Computer Programming by Weinberg. More descriptive than prescriptive compared to many other books, written in and about the same period as The Mythical Man-Month.


Just want to add vote for Design of Everyday Things. If you are into creating anything that other people use (software, code, appliances, doors), you should read this book.


Just be warned. You're going to spend a couple of weeks after having read it being very frustrated with people influencing your world who apparently didn’t read it…


The top book imho is The Pragmatic Programer.

Here some other recomendations

- Designing Data-Intensive Applications - Tidy First?: A Personal Exercise in Empirical Software Design - A Philosophy of Software Design - Refactoring UI - The Software Engineer's Guidebook - https://blog.rstankov.com/programing-books/


Controversial take: reading books to get better at software is like reading books to get better at swimming. Like people don't get better at math by reading books about math... So you should go read code. But reading code is boring if you're not also writing code (same goes for math) so my real recommendation is to go find a big OSS project in an area you're interested in and start contributing. If you don't know how to start doing that, pick one with a GitHub and go look through the issues. Any serious project will have a label like `easy` or `first PR`, respond to one of those and tag one of the contributors asking something like "can you give me a code pointer so I can get started". And off you go - guaranteed to make you better at software if you do it for long enough.


I agree with the gist of your comment but I think people can benefit from books about maths. A classic example that comes to mind is Polya's "How to Solve It". It's about the meta of doing maths (or the tacit knowledge of a great mathematician), not about specific fields or theorems.


Yes if you know absolutely nothing about writing proofs then polya's book is good. But that's it - after that "onboarding" you're never going to see a professional mathematician reading another such book.


I still got stuff out of it during my PhD (in mathematics, though I never finished). I think you might underestimate the value of tacit-knowledge-type stuff, especially from skilled mathematicians like Polya. It's interesting to see how they tackle hard problems, and to compare it to how you would do the same - at the very least I have a much less developed philosophy about it. Terrence Tao has blog posts about his problem-solving meta as well, that are interesting (to me) for similar reasons.


I think both are useful, and generally if you have the time to do both, you should.

For example, my go to when using a new framework or library that'll be a core part of a project, is to read its documentation in its entirety. I did this with eg Vue. It's a _huge_ time saver, and the big key, is that it reveals things you would never have known existed! They're things which you wouldn't have stumbled on yourself, but which come in handy in certain moments. Or they're things that would waste your time googling, and which might be difficult to understand out of context. The docs also let you understand the "spirit" of the tool you're using, which will let you work much more smoothly with it, and avoid unintentionally fighting with it and how it was designed to do things.

This is also true for more abstract concepts in CS, which might not come up often, but which are smart abstractions that can come into play at key moments in your projects.

Also with math, most math learning is done by books -- books with exercises, yes, but still books.

But at the end of the day, I think what matters is don't get stuck in one mode. Don't _only_ learn from books, since that won't give you the skills you need. But also don't _only_ learn by doing, since then you'll basically be wasting your time re-discovering the last 100 years of programming/CS experience. Do both!

I think an artist in YouTube summarised this best many years ago. He describes 3 ways to improve at something: innate improvement, inspired improvement, and developmental improvement. Innate improvement being by volume--i.e. if you do it every day, you'll get better even if you're not consciously trying to improve. Inspired improvement is using those bursts of inspiration/interest to propel your skills forward. And developmental improvement being the more traditional, sit down with a book and learn/practice approach. All are useful and contribute to improving, so use them all where possible! Jazza recommends making projects that allow for all three possible types of improvement.

Video: https://youtu.be/Bu3ulVhO3z4


it is not either or. You can do both.

I'm sure a swimmer who reads books about swimming in addition to swimming is better all else being equal than a swimmer who just swims.


> who reads books about swimming

Can you show me such a book? Ie a book that teaches one to swim (different strokes etc) aimed at a professional swimmer (athlete).


I think your point makes sense, but the comparison of programming to swimming loses the thread of thought a bit. Swimming is not my forte, but there are books by professional marathoners on how to train for marathons, for example, that are valuable to read for forming proper training plans as opposed to "just figuring it out".

I think your opinion on OSS/large codebases makes sense, but I don't think it's an either/or situation: reading should _support_ actual coding, similar to how studying a grammar textbook for a foreign language is there to support actually speaking/listening/communicating in that language.


Can't show you one for swimming but if you're a karateka, then you can do worse that spending some time reading books like the Bubishi


It's like reading books in order to get better at writing them... sure it kinda works but not really. You get better at SWE by building things!!

The field has a lot of gurus who trick newcomers into falacies like 'clean code' when, instead, they should be out there banging together rocks like a JavaScript caveman seeking fire (Lisps).


I do think sometimes reading books about coding might actually make you worse since you might misunderstand the rules gained from there and try to use them everywhere even if they don't make sense.

So you need some sort of built experience that will allow you to consider those rules critically, and only add them to your toolset if it does seem to make sense for you and you understand why, you have past experience where you think "oh - that would have helped me a lot".


The already mentioned The Pragmatic Programmer, 20th Anniversary Edition is so far the best I have read. It's not overly specific to one single thing, it tries to teaches general principles and good practice.[1]

I also have a personal recommendation for when you want to better understand testing, QA, or want to/have to work with QA people. [2]

[1] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2... [2] https://www.amazon.com/Lessons-Learned-Software-Testing-Cont...


2 books I consider excellent:

- A Philosophy of Software Design by John Ousterhout - Domain-driven Design: Tackling Complexity in the Heart of Software by Eric Evans

They both manage to explain some ideas that are really important, in a very simple way (which makes me feel like an idiot).


I would advice not to concentrate on coding per se. Coding fashion is volatile, today's good practice is a tomorrow's code smell. So instead of "programmer's books" I would suggest How Big Things are Done by Bent Flyvbjerg and Den Gardner. It's a new book (2023) and while it touches software engineering a bit, as the title suggest, it's more about getting big things done.


More overarching: The Phoenix Project

For a good understanding of the basics of architecture: https://www.amazon.com/Web-Application-Architecture-Principl...


Systems Performance: Enterprise and the Cloud (2nd Edition)

https://www.brendangregg.com/systems-performance-2nd-edition...

and

BPF Performance Tools

https://www.brendangregg.com/bpf-performance-tools-book.html


I feel that I learned a lot from Joel Spolsky's blog (the top 10, in particular)

https://www.joelonsoftware.com/


His book is a great read. Had me laughing out of the box.


I would say it's still worth reading The Inmates Are Running the Asylum. I'm sure some of the examples are antiquated, but it's a really interesting book.

Programming Pearls too would still be worth reading


Peopleware is 100% worth it still today.

You’ll just get angry when writing it. We had written down solutions to problems with teams and offices in 50 years ago but just refused to follow them.


Not a manual, handbook, or guide per se - but I've learned an awful lot from reading

Coders at Work: Reflections on the Craft of Programming


Look at Casey Murrey's Clean Code horrible performance youtube video:

https://www.youtube.com/watch?v=tD5NrevFtbU

I also watched clean code videos and used it in practice, and why it _felt_ right my code size blew up and actually it got harder to understand by other people instead of easier.

Nowdays my main guidelines are getting a balance between less lines of code (while still readable), readable variable names and better performance.

Also I may get hate here for it, but I learned a lot from watching George Hotz programming tinygrad (available on YouTube).


The Mythical Man-Month[0]

“Old” but amazingly relevant today.

[0] https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month


This book surprised me by how good it is -- it distills a lot of tribal knowledge about how software engineering works at the mid-level to (early) senior engineering levels, based on the author's experience working at SV companies.

https://www.amazon.com/Effective-Engineer-Engineering-Dispro...

If you're experienced (senior or higher), it's still a good read, but fewer things will surprise you.


Others have given a lot of good suggestions about books for general software engineering. Some book on how to structure code and some book on how to be a professional and some book on the human aspect of the profession would all be beneficial. Pick one that covers each of these areas and they’ll provide you a good foothold.

I’m surprised I don’t see more advice to read a language- or domain-specific book. If you know what type of technology you want to work on and what language(s) you want to use, I’d read a book or two to gain expert-level understanding of those languages or domains. I cannot tell you how beneficial it has been to me to read books covering all the intricacies of C, C++, and Rust. Not to mention countless pages of documentation covering the Linux kernel, shell scripting, etc. Even if you have great general software engineering skill, you still have to be able to quickly read, write, understand, and modify the code you work on. You never know when you might find yourself 50 files deep in an exploration of why some open source software behaves a certain way that’s really boiling your blood, or when you need to parse the code to find an undocumented feature you’re certain exists (or, if not, to hack it in). Knowing the language is very beneficial for this, and getting eyes on open source code to recognize common patterns is very useful.


Here are the subjects where I see both beginner and experienced developers fail and yet what separates the children from the adults in the room. So read absolutely any (multiple) books on these subjects:

* measuring things (evidence gathering, performance, comparisons, stats, research). Most developers cannot do this on any level and yet have the balls (stupidity) to advocate so boldly for their opinions.

* data structures. There is a very old best practice: composition over inheritance. That advice runs far deeper than it sounds because all aspects of a good application should be interchangeable and extensible structures. That applies to both theory like functional programming as well as practical like interfaces, APIs, and data in transport.

* writing. Programming, in the brain, is no different than writing an essay in natural language. It requires executive planning, expression, organization, and refactoring. The better you get at writing prose, articles, and proposals the easier it gets to write the first draft of an original application. It’s so much more than just writing documentation and most programmers struggle with all of this.

* transmission. Read the protocol RFCs and attempt to write original implementations. Most programmers cannot do this and yet a deeper understanding of data in movement will provide capabilities you, and your competition, can never before imagine.


My favorite software books of the last few years:

"A Philosophy of Software Design" is mentioned a lot, +1

"The Missing README" is full of pragmatic advice to get from 'my code works' to 'my code is in production'. Many of the barriers to success have nothing to do with algorithms and everything to do with the organization running the project. It's marketed to new engineers, but I think anyone who writes software would get something out of it.

"Elements of Clojure" by Zach Tellman is a fantastic high-level architectural philosophy about how we build and compose abstractions. Only wish that the title wasn't tied to the Clojure programming language (most of the book is applicable to any language despite the title) and was a bit longer.

"Tidy First" is the first in a series by Kent Beck, a quick exposition on how to separate structural changes (architecture, paying down tech debt) from behavioral changes (new features, bug fixes). You need both, and you can use economics as a guide for when to invest in one or the other. But you need to treat them differently.


Domain-Driven Design is fantastic.

Test-Driven Design by Example is a good (and fun) read.


Two of the best books for software engineers are actually not specific to software engineering:

  * “The Design of Everyday Things”. Have you ever pushed on a pull door, or vice-versa, because it was unclear how it worked? Designers call those doors “Norman Doors”, now, after the author of this book Donald Norman so effectively dissected and criticized them (among plenty other objects). Too many APIs suffer similar problems—and if you don’t want yours to, this book is a great place to start.
  * “On Writing Well”, by William Zinsser. Good code and good prose have a lot in common: they know what they’re trying to do, are stripped to their clearest components, and have internal structure that supports understanding. Add to that the fact you’ll be writing lots of prose anyway (design docs, postmortems, etc), and the value of writing well should be clear.


The Passionate Programmer is still high up in my list. It's more about ways to get better at software engineering, and less about specific tools or technologies.

Depending on the tech stack you're interested in, I would also strongly suggest reading foundational books that go deep into that platform (e.g. the Java Language Specification if you're into Java [1]). These are not things you necessarily need to read end-to-end or understand completely, but your global understanding of your chosen platform will expand significantly.

Systems Performance by Brendan Gregg is another useful classic. While it's about performance, it touches upon a huge number of important topics (from memory allocation to pretty graphs), perusing it will make you smarter.

[1] https://docs.oracle.com/javase/specs/


The Hitchhikers Guide to the Galaxy

Surrounded by Idiots

Meditations


wait a minute... i see what you did here...


This book has software engineering concepts that I never did see or hear anywhere else: "Expert C# Business Objects". Its concepts are language agnostic, even though it has C# examples. You might try some videos by the author of that book too.

Related to this book is what we call "vertical feature slicing". (I'd be curious to know what other books cover this topic.) There are some Youtube videos on the topic. There was a great 2-hour video from 20 years ago that influenced me. Unfortunately, I don't remember the title and cannot find it today.

The video "Simple Made Easy" had a profound influence on my programming: https://www.infoq.com/presentations/Simple-Made-Easy/


I have what might be considered an unpopular opinion here. What you’ve read already is more than enough. And most of the books that are recommended here are going to be a massive waste of time over what you’ve already read. What you’ll be better off doing is read code available in your domain of interest.


Totally different suggestion, look at how good woodworkers[0] or artisans are creating there pieces. These are unique pieces but reusing common well mastered technics.

It takes time for them. It takes time for us. The small details are ironed out along the way but the big picture, the concept, is defined/designed before.

Note that I really like the books listed up to now, they are not "dependency injection in Typescript using framework x, y or z" kind of books, more general philosophy of coding (with people). Going to this upper level is for me where you go from good to great. And myself, going to my 50s, I am still learning...

[0]: https://m.youtube.com/watch?v=sL96mw1uCmA


Designing Data Intensive Applications


Seconding. This book will get you hired.


The main thing I learned from this book was about LSMs and it solidified my understanding of B trees. I think I'd mostly overrated tho.


When I first graduated I read a bunch of tech focused books: they’re all helpful but I think practice and learning from more senior engineers is the most effective road to mastery! You can probably get away with not reading any of these books if you have good coworkers :).

That being said, these have been my favorites:

- designing data intensive applications (a great way of understanding systems + the basics of SRE)

- the senior engineer (I love the prototyping process he lays out)

- the effective engineer (lots of good gems for approaching prioritization)

- debugging (by David agans)- a great resource for a formalized debugging process if you don’t have one

- on writing well (I’m halfway through this, but it has been indispensable for writing tickets + messages at work)


Unwritten Laws of Engineering by W.J. King from 1940. This has nothing about software engineering in particular but a useful list of Do's and Don't for workplace. You would be surprised how much of this is relevant today.


Late to this but as I don't see it suggested, then the following page can really come in handy when wanting book suggestions from HN.

https://hackernewsbooks.com/

I have no affiliation.


Designing Data Intensive Applications is a great book.

I read this years ago and regularly recommend it, especially when people are all over talking about some special queue or database technology. I find so many people don’t understand even how databases work and it’s crucial to application performance and structuring. Adding queues works to relieve server load but if you get swamped by messages you need to make an active decision on how to handle that - and maybe a queue isn’t the best idea if you can’t lose them.


If you're also interested in Software Architecture (at least the high-level), then I can also recommend https://architectelevator.com/book/ by Gregor Hohpe (who also wrote another long-time classic: Enterprise Integration Patterns).

Another one I found very helpful is Designing Data-Intensive Applications by Martin Kleppmann.


I think it makes sense to create a book list and have a yearly target for them. One book a month is reasonable for medium sized books. HEre are some that I found useful.

1. The Practice of Programming 2. Programming Pearls 3. Go Programming Language 4. Architecture of Open Source applications - https://aosabook.org/en/


[Off-topic]

I'm getting an eerie sense of Deja Vu.

I remember reading this exact thread (exact question, exact replies) a few days ago.

But right now it says this question was posted just 6 hours ago (right now the time is 2:35 pm 1st September UTC).

Either I'm going crazy or there's a bug with the time here.

@dang please tell me that I'm not going crazy, or at least that it's just a simple glitch in the matrix.


the thread was boosted, which makes it appear as if it and the old comments were posted more recently than it actually was. search "second-chance pool" to find comments from dang explaining it in more detail.


Oh! Okay! That's reassuring, thanks!


Popular topics sometimes get reposted, with the "submitted" dates reset to reflect that. You aren't going crazy.


> with the "submitted" dates reset to reflect that

Huh. Okay.


SICP and designing data intensive applications.


A lot will depend on where you are in your maturity as a programmer. And what sort of work you want to do.

I've always done well following Don Lancaster's advice: Hit the basics, HARD.

Most modern software "innovations" are really just a restatement of David Parnas' paper from 1971. He suggested programs should be split up so that the data used by modules can't be affected by the other modules. "Data hiding."

Once you get a grounding in the history and literature of programming (which all other professions do without thinking), you'll start to see the "sameness" among all the supposed difference. Once you see the "sameness", you'll know what is truly important to know/master, and what is not.

As a recent grad, I'll tell you that the first thing I learned was to ignore all the "software engineering" stuff that schools teach. The reality is that I would be asked, "Build a tool to do X". So I'd start through the process, building a design and the data flows, starting to build the code. Then I'd get "It also has to do Y." And I'd have to throw away most of what was written.

Eventually, I learned the two rules Ken Thompson taught:

1) give users something useful in two week, not the whole problem solved. 2) when in doubt, use brute force.

That's it. With attention to fundamentals, you can clearly see that "Agile" is just a bunch of fancy words (and vendors selling tools) telling you to do that same thing. Only Ken talked about that in the 70's.

What you'll find is that getting a tool into the hands of users will generate new features based on what it already does. No more blue-sky wishes. And it will allow the tool to evolve into what they really want it to do. Which no one ever knows when they start. All the best software followed that path to greatness. (Which you'll see when you read the history of your chosen profession.)

So learn the history. Learn how computers work (not the "Von Neumann" stuff). Get a computer engineering book and learn about bit-slicing and clocks and microcode. It doesn't matter that you're not a hardware guy; you need to know what your code is actually doing, down on the metal.

Never stop learning. Read constantly. Read books you'll never find a job with, like SICP. (I once had to write a loop in a language without a loop construct. But I had read SICP, so I knew if it supported recursion, I could make a loop. And I did.) Don't read trash. Don't bother with the "current hotness"; if it's good, it's probably just a restatement of the old and if it's bad, it'll go away.

I'll just leave with an ancient aphorism: 40 can't tell 20. There's just a gap between what an older person has learned about the world, and what a younger person imagines the world to be. That different can be called "experience", but the fact is I remember perfectly the pearls of wisdom dropped on my by the "old men"...and 20 years later, I was them. So I offer this small essay, knowing it'll probably be rejected, but hoping that just this once it does some good for someone.


Your essay is filled with strong and agreeable opinions. I appreciate that I get to learn about them from a recent graduate. Thanks.


Life would be so much better if Devs were familiar with the UNIX Philosophy — https://en.m.wikipedia.org/wiki/Unix_philosophy


The best book about software engineering I found so far: https://abseil.io/resources/swe-book


I think learning about how your applications will be supported once live is important so always recommend the Google SRE book.

I think the most important chapter is on Simplicity of your build and code.

Definitely worth a read


Maybe not so obvious, but - Stephen King’s “On writing”. When I read it ages ago, found funny how writing the books is similar to writing the code.


Unvle Bob even gave up on clean code and just chose clojure


How to Win Friends and Influence People, Dale Carnagie


Similar discussions: https://pastebin.com/eCRrLakN


Alice in Wonderland


The sequel "Through the Looking-Glass" contains one of the most fitting parables on software engineering ever written: The Red Queen's race...


Joel on software hasn't been mentioned. It's a great book. Might be a bit dated, but it's a super fun read, and smart.


I'm a big fan of the reading list and structure of teachyourselfcs.com


Wondering what people's opinion on the _Domain Driven Design_ book is.


I'll be honest. I hated it. Any book that contains the text "obviously ..." loses my trust. I can't respect an author who's too lazy to make his point.

He used it quite a few times in the beginning of the book.

"Obviously" is used for two reasons. Derision, or to escape criticism.

I'm obviously right.

Now the real critique. The book assumes experts are on hand to ask, and that terms don't change. I worked at a place where what we called user changed 3 times in 4 years. Runners/workers/producers. You would know when a bit of code was written based on the names for users in the api.

It also assumes that all experts agree. I worked on an education app where teachers in schools were the experts. Different schools in the same city had different terms for the same thing. So which expert do you trust.

Is it a trunk or a boot? Is it an elevator or a lift? And that's if you're writing an app for english only speaking experts.

Finally, we have to understand the mind of the dev, to know how they organised their walls. The dev that left the company 5 years ago.


I'm eager to hear other opinions on Eric's DDD book too :-D I still don't understand it!


Waist of time.


It's a nice system but far too complicated for the world we live in, where most tech companies, especially banks, are filled with imported labor or outsourced globally.

DDD requires a certain discipline and dedication I just haven't seen in my career across many companies.

Good luck getting more than a handful of people to not only digest the big books but also structure all their code and company around practicing it.


Novels to foster and train an instinct for creative solutions.


Paradigms of AI Programming by Peter Norvig is excellent.


harry potter lord of the rings dune game of thrones berserk vinland saga robinson curso : happy reading time!!!


The Programmer's Brain by Felienne Hermans


Death March by Ed Yourdon.


https://saasbook.info (Which I haven't finished lol).


Terry Pratchett.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: