I'd also read the books from Teach Yourself CS (<a href="https://teachyourselfcs.com" rel="nofollow">https://teachyourselfcs.com</a>):<p>- Structure and Interpretation of Computer Programs<p>- Computer Systems: A Programmer's Perspective<p>- The Algorithm Design Manual<p>- Mathematics for Computer Science<p>- Operating Systems: Three Easy Pieces<p>- Computer Networking: A Top-Down Approach<p>- Readings in Database Systems<p>- Crafting Interpreters<p>- Designing Data-Intensive Applications<p>Other books I've seen:<p>- Computer Graphics From Scratch<p>- Haskell Programming From First Principles<p>- Zero To Production In Rust
I recommend "Developer Hegemony". Coming from a career in FAANG, it's helped put words to what bothers me about the power dynamics and management practices. The book also presents a picture of what a healthier and more empowered "software engineering" role/world could look like (one of my 2023 goals is making significant career moves in that direction)
Reading books is great! And curating a list is useful and fun.<p>But you have to be pretty careful when you say things are a "must" since that's... pretty hard to prove (and can just make people feel bad). And the proof has already been pointed out as not true in this thread. Unless we all want to start evaluating eachother's programming ability virtually.<p>Again, lists and reading is great! And it's probably better to (try to) read any of these books than not.<p>But for the folks who try the books and can't get through them (like me and SICP), I'd say don't worry about it.<p>I have my own [0] list of books I think devs should read but I just try not to say "must read".<p>[0] <a href="https://notes.eatonphil.com/books-developers-should-read.html" rel="nofollow">https://notes.eatonphil.com/books-developers-should-read.htm...</a>
I read two of these last year and I'd recomend both, but I wanted to give my two cents on them.<p>The Phoenix Project: I really enjoyed reading this, but it's told as a story about fictional characters working at a fictional company, which I didn't expect. Because of the way it's written, some other people I know who read it found it a bit too fluffy. Also, from what I've heard, it's pretty much an IT focused version of The Goal by Eliyahu M. Goldratt. The Phoenix Project focused more on IT than software development, but there's also a sequel called The Unicorn Project that is supposedly more focus software development and dev ops.<p>An Elegant Puzzle: There's a ton of good stuff in here, but it felt a bit like reading a textbook or a white paper. Larson's writing style is really dense and dry. I found myself reading a paragraph or two and then needing to take time to digest what I had just read, which made it a really slow read.
> “Software Engineering at Google: Lessons Learned from Programming Over Time”<p>Isn't Google's software engineering culture kind of a joke right now? I've spoken to multiple ex-Googlers and they tell me they leave because everything moves at a snail's pace. From the outside looking in, it seems like absolutely nothing is being done in Google and I would not want to replicate their engineering culture in any company.<p>Please don't take this as flame bait and I'm open to discussion about what I'm missing. I feel like for people in the know, Google has a reputation for being a "retirement home".
I see SICP listed on every list but I really feel its becoming Knuth-esque. I mean, I didn't learn through that specific book, but after going through it a couple of years ago I found that its kinda alright, but I don't really get this legendary status it has. I've also seen this opinion shared with many seasoned vets throughout my career, just feels overrated.
I read Build, The Pragmatic Programmer and A Philosophy of Software Design last year. All three were excellent reads. My favorite take away from A Philosophy of Software Design was to try to make low-level functions more general and high-level functions application specific/concrete.<p>I have been working on improving my API design skills, and I felt that particular insight helped evolve APIs nicely as the spec updates or I need to add new features to my projects and reduced the need for refactoring and big design revisions.
A Discipline of Programming by Edsger Dijkstra. It’s an approachable introduction to a frankly under-taught approach to programming.<p>Being able to apply mathematical reasoning to programming is perhaps the main reason to use a functional approach. But mathematical reasoning isn’t restricted to functional style programs! All imperative programs can be described by purely functional mappings between points in a program state space with each in scope variable naming a dimension.
<i>SICP</i> shouldn’t be on this list. Few people actually read it and most just worship it unread like a bible. It was Hilfinger’s assigned text in 61A at Berkeley but without any assigned readings.<p>On the other hand, <i>The Little Schemer</i> which has a lot of the important ideas from SICP might be on a list such as this. But it’s too accessible to warrant much respect.
A new book I read in 2022 that I can really recommend is Effective Software Testing by Maurício Aniche. Very pragmatic, useful tips on how to write tests. I have been developing SW (and tests) for a really long time, but I still learnt
a lot from it.<p>A more detailed review here:<p><a href="https://henrikwarne.com/2022/06/19/effective-software-testing-a-developers-guide/" rel="nofollow">https://henrikwarne.com/2022/06/19/effective-software-testin...</a>
I guess the question is: what is the maximum number of pages from these books one can realistically digest and internalize in a year and how do sort on those pages for the most valuable ones
"Vert.x in Action" Julien Ponge (2020). I've been reading it for a new job I'm in that uses Vertx. Best framework and textbook I've seen in years. So refreshing to write Java without Spring magic. I'm not loving reactive everything, but its powerful.<p>Its more than just about Vertx though as it has a great simple demo project that uses Mongo, Postgres, Zookeeper, Kafka, Artemis in containers, which is some other components I've been trying to make use of too.
I find that the practice of "software engineering" has a fuzzy distinction to "computer science." I highly recommend the following books that helped me out on that journey:<p>- Continuous Delivery by Jez Humble and Dave Farley<p>- The Pragmatic Programmer by Andy Hunt and Dave Thomas<p>- A History of Modern Computing by Paul E. Ceruzzi<p>- Version Control with Git by Prem Ponuthorai and Jon Loeliger<p>- and SICP. Understanding it is like accessing a new dimension of power.
I wonder if it's time to prioritize newer books with mysterious titles such as "Transfer Learning for Natural Language Processing" over traditional SE books. I imagine this year we'll see some "Programming in chatGPT" ones too. Are we experiencing a revolution in code generation or is it mostly hype still?
I am surprised nobody has mentioned this one. It is free and available online:<p><a href="https://softwarefoundations.cis.upenn.edu/" rel="nofollow">https://softwarefoundations.cis.upenn.edu/</a>
Are there any books regarding the history of programming? Going from Visual Basic to Vim to all the fancy languages we have today. Or anything on how what we write as code gets translated into binary and what happens to our computers when the code processes?
I'm just starting to get into reading books to upskill myself. I'm just curious, do the knowledge you gain in these books not outdated and still applicable to modern software development?
“This book is a must-read for any serious software engineer.”<p>This isn’t necessarily wrong but it always reminds me of the era when I had severe impostor syndrome. I haven’t read any of these books and I’m doing very well. I guess I’m just not serious enough. :)
As a software engineer, staying up-to-date with the latest developments and best practices is essential for growth. One of my favorite (and what I feel is overlooked) methods for growth is reading books. We spend a large part of our day reading Stack Overflow...