As the author of Computer Graphics From Scratch, I still can't wrap my head around people mentioning it in HN comments. Blows my mind every time :) Thank you and happy new year!
As the author of Teach Yourself CS I would definitely suggest against trying to fit this in a year! Maybe aim for CS:APP and 1-2 others, and if you have time for more that's a bonus. Most of these are books to work through, not "read".
Thanks for writing it. Yes, definitely didn't mean to imply that it could be done in just a year, just that it's a useful resource in general that people might not know about.
To be fair, the second link you provided is for the 3rd edition and lists something like 20 errors (including typos, etc.) for a book of approximately 800 pages.
* Database System Concepts (https://www.amazon.com/Database-Concepts-Abraham-Silberschat...) - specifically, the chapters on storage and query processing, it's a huge volume otherwise. Also, "Database Systems: The Complete Book" is basically an older version of it.
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)
Really great to see a mention of "Developer Hegemony" here.
The author compares software engineers to doctors or lawyers.
In a law firm, the partners call the shots and the rest of the staff is there to support them. In tech companies, the structure is inverted. The engineers are at the bottom of the power hierarchy, even though it's the engineers that generate the most value.
The author suggests that developers should instead become "efficienciers". Rather than being code monkeys, "efficienciers" are able to solve problems via their use of technology.
@losteric I've been thinking about this book for a while. If you're willing to share what your plans are, I'd love to hear more. To me it sounds like some sort of freelancing which is rather daunting.
I've recently read Developer Hegemony. While I agree with their critique of the status quo, I don't think their alternative approach works for software engineering in settings other than agency work for non-tech clients.
Law firms are a way of organizing game animals. Two zebras have no need to compete over eating from the same patch of grass. One zebra just moves over by a few meters. There's enough grass for everyone. Even if there isn't enough grass, fighting over grass is not energetically efficient. You burn more calories than the grass is worth. In law firms, a client is generally handled by at most one partner, and there are enough clients to go around to keep all partners busy while allowing them to work fairly independently. Tech companies that do agency work for non-tech clients may or may not be a little bit like that.
But most tech companies are in a situation more comparable to pack hunters. A single lion can't take on a buffalo. It takes a coordinated effort by a group of lions. When the buffalo is down, there's a pecking order determining who gets to eat first. In case of food shortages, animals lower down the pecking order are in a difficult situation. They can starve to death in a large successful pack, or start taking on risks by going it alone or in packs that are too small. (If the group of predators is too small given the size of their chosen prey, then predators themselves might easily suffer injury). So competition for rank is to them a matter of survival.
Social behaviour among game animals fundamentally differs from social behaviour among pack hunters and it's all a function of the ecological niche they inhabit.
Similarly, law firms are organized very differently from tech companies and it's a function of their products / markets / business models / stakeholders / general situations.
...so I'd be very careful about the law firm analogy.
If I understand you correctly, you're saying that lawyers are primarily solitary and software projects require a team? Do I have that right? Law firms still have a hierarchy: there are senior partners, junior partners, articling students, etc. From my lay understanding the business is still organized around "a lawyer" being the top of the food chain.
> Similarly, law firms are organized very differently from tech companies and it's a function of their products / markets / business models / stakeholders / general situations.
It's hard to disagree there, purely from a historical perspective. Google was started by a bunch of developers and it looks like a traditional corporation now with layers and layers of middle management. Perhaps this is the most efficient type of an organization for a large software maker. One interesting alternative are tech coops [0]:
> Worker-owned cooperatives are business enterprises that are owned and governed by their employees. All worker cooperatives have two common characteristics: 1) member-owners invest in and own the business together, and share the enterprise’s profits, and 2) decision-making is democratic, with each member having one vote.
Just a nit: as a dev turned lawyer, I would say law firms don't need to be organized as they are. That's a whole topic, and I don't think it impairs your main point, just saying: don't assume anything in law is optimal, balanced, or rational.
I didn’t read that book but I kind of followed that path. A doctor doesn’t practice health, but heal people, so indeed writing code and making a working software is not the point for me. The obvious example is an independent game developer that wants to make a game for people to have fun.
There is no grand conspiracy of management, it’s just that big companies are usually more akin to factories. There you can’t both be on the assembly line and make strategic and product decisions.
I don’t think freelancing by itself is a solution. Maybe you mean consulting? For me what works is working in small companies and early stage startups. But there are maybe larger companies with alternative organizations that could do it.
I'm still not entirely clear on freelancing vs consulting to be honest. I've worked both in smaller and larger companies and the management track simply makes more money.
> In a law firm, the partners call the shots and the rest of the staff is there to support them. In tech companies, the structure is inverted. The engineers are at the bottom of the power hierarchy, even though it's the engineers that generate the most value.
Hmm, as a software engineer, I'm not so sure this is true.
I'd have to sell my product to generate revenue, and I'm not a very good sales person. I can't just generate value by writing code. I need people to pay me money to use that code.
I agree 100%. The last thing I want to do is sell ('cause I've done it before). I'm terrible at it.
But:
> “Consider a law firm. Do the founding partners go out and hire a Lawyer Manager to order them around, and then do they hire a VP of Lawyering to order the manager around? Do they then hire a CEO to rule over everyone and a CFO to handle the finances and a COO to schedule court dates and such? Of course not. There’s no historical precedent for all that fluff. Rather, they handle facets of the business themselves. What they can’t or don’t want to handle, they delegate to subordinates that they hire. The partners don’t specialize in finance, sales, marketing, or operations. That would be silly. But they understand enough about it to act as the boss.”
Can I be successful as a terrible salesman with a product? Sure I can.
Can an amazing salesman be successful without a product? Nope.
I really didn't like that book. The author has some good points, but they are already mostly discussed on his blog.
Meanwhile, much of the book is the author pretending to be an economic historian and talking (in a very shallow way) about medieval guilds or something.
Reading books is great! And curating a list is useful and fun.
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.
Again, lists and reading is great! And it's probably better to (try to) read any of these books than not.
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.
I have my own [0] list of books I think devs should read but I just try not to say "must read".
I can not stand the dogmas: You "must" read this, you "have" to use this IDE/text editor, you will perish a slow painful death if you program in language X and not language Y.
Read what you want, use what you want, please share with me what you like and don't like but please do not tell me what I must do and I must use.
I read two of these last year and I'd recomend both, but I wanted to give my two cents on them.
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.
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.
I thought The Goal was more generally applicable. Its core idea ("theory of constraints") is described in terms of a factory floor where different workstations have different throughputs/latencies/reliability; you could apply that to a diagram of a distributed system [0], CPU [1] or server [2].
Phoenix and Unicorn project are essentially The Goal applied to software development. Reading The Goal first helped me get more out of Phoenix and Unicorn, I think. All 3 are great.
There are some excellent sequels to "The Goal", especially, "It's Not Luck," which goes on to take the theory into product and market design. It overlaps somewhat with Christensen's work on Jobs to do.
I've found lots of value in looking at all kinds of systems with this lens, though, like all things, it helps to not overdo it.
I've read The Unicorn Project. I haven't read the Phoenix one though so I can't draw comparisons, but I enjoyed it immensely because it describes how a big auto parts corporation works from different points of view. One chapter I particularly liked was more about marketing and crm than devops, although there's lots of that in there too.
Chiming in here, I love this style of book and have read the whole genre. There should be more. For someone who's just looking up from the keyboard at how to actually do things in an organization, with people, and how it all works they're absolutely thrillers and I raced through.
> “Software Engineering at Google: Lessons Learned from Programming Over Time”
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.
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".
> Google's engineering culture, at least a few years back, was insanely good given that reality.
If by "a few years" you mean 4-5, I have to strongly disagree. I witnessed extremely sloppy and incorrect general logic, even worse pathologies around concurrency, and disagreement between:
1. tech team gatekeepers
2. language police gatekeepers
3. mandated framework gatekeepers
when 1+2+3 all disagree and decide to block approvals, it's just comical. Especially since everybody is so sure they know "the right way". The high horse on which many devs at Google sit appears to be purely misdirected/unwarranted ego stroking from many people's point of view who are just trying to make practical, every-day decisions.
I feel like that's a terrible use of their capital if all they are trying to do is just not screw things up. I'm not a shareholder but if I were I'd rather have my money returned to me than have it spent on a bunch of projects that will get nowhere because the goal is avoid risk taking.
It’s not only “don’t screw things up.” They still develop features, they just go through a gauntlet of design review, experimentation, and then launch review.
Fair criticism, I have seen similar posts and articles about things inside there now. But the book is not so much about the current culture or setting now, but more on the authors experiences and what things have made the company successful long term from an engineering perspective. Good book to get insight on different topics or areas.
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.
Maybe it depends on where you are in your journey when you came across it?
For me, I came across it in the early 90s, as it was the first text for my CS class in college. I devoured it and it still holds a special place in my heart.
If I read it for the time now, would it be the same? Possibly not. (To wit, I read _The Catcher in the Rye_ for the first time in my 40s. I found it "meh" but can understand how reading it as a teenager would hit me differently.)
WRT when people do it: I have heard from some people that they tried going through it early in their career on their own or as part of a course, and either they could not finish it or did not see what the big deal is. But then they tried again years later, and they could see why so many people recommend it.
Definitely, the journey is a meeting of inner state with exterior environment. I read Catcher in the Rye in my teens (but almost 50 years after first being published, in the 90s) and also found it meh.
The book’s idea will carry us for many years but the book is introductory nonetheless. A few years of rigorous CS education definitely calls for deeper materials, but I wouldn’t call the book “overrated”, at least not for novice engineers.
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.
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.
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.
>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.
Agreed, it's a good book, although everything in it isn't great. I think he goes overboard when it comes to comments for example. Probably most famous for the concept of "deep modules" (the interface should be a lot simpler than the implementation), which I like. I also really liked the idea about defining errors out of existence, e.g. a substring method can be defined in a way that it never needs to throw any exceptions.
It's one of my favorites. I've read it a few times and always find it insightful and motivating. It's an easy, quick read that I recommend to anyone that wants to build better software.
SICP 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.
On the other hand, The Little Schemer 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.
The whole The Little|Seasoned|Reasoned Schemer plus its other variants The Little ML'er|Java|Prover|Typer are some of the most mind bending books that you will ever read ever. And it is not the just the end result. Reading these books well will teach you socratic method of teaching/learning, which is great in itself. And will help you teach yourself a wide variety of concepts.
Only real problem is many people struggle to adopt to that socratic approach and for somebody who is not into it will just not get it. Have seen this time and again, while I had my jaw on the floor reading them, some of my colleagues could barely progress beyond the first few pages. So they aren't exactly accessible to everyone.
Why are people downvoting and flagging this comment? The top and bottom are literal quotes from The Little Schemer and the rest is just a short review of the books and an honest assessment of the trouble with the Socratic method (it doesn't work for everyone).
The Little _________ books themselves are strange, you will either get them or you won't. So it is already a binary classification. The books don't follow a normal book like flow and its basically a giant teacher-student like 1 - 1 mentoring-- building the lesson up from basic axioms, revealing the rules of play slowly, and helping you discover the concepts yourself along the way.
>>Wonder what's up with functional languages that leads them to do this.
One way to teach dry math'y concepts is to make them fun to learn. Serious Math people mind find them irritating but for the remainder crowd it is a fun exercise.
Sure, though I suppose fun is in the eye of the beholder. Grokking Algorithms is illustrated with cartoons and examples that kids could understand, but it doesn't indulge in the same weird quirky whimsy that some of these texts do. It's almost as if they're written in some lost lolcat dialect.
It is not infantile, it is just a different way of approaching a problem. Instead of telling you what things are, they just ask you questions so that by answering them you discover the things yourself.
There is a big difference between two approaches. In the former you get facts as knowledge. In the latter your invent the knowledge yourself, and understand the processes, whys and hows you got there. The latter is a far better way because its hard to forget what you invented yourself.
Basically all throughout the book(s), they authors use food names as variable, function names etc. It is indeed a nice idea because people do tend to associate good memories with delicious food. Especially if the food is greasy or sweet!
That quote This space is reserved for Jelly Bean stains is basically a filler sentence at the end of a chapter on a page, which happens to be high up in the page, the remainder of the page is basically empty, so they put it in as a joke.
This is not any different than the joke at the beginning of the 'Camel Book', Laziness, Impatience and Hubris, the three great virtues of a programmer.
You really should read those books, its one of those unique kinds of books that use a very innovative(albeit a very ancient) technique to teach you some very mind bending concepts. Its is possible that the approach will help you in understanding other things as well.
I'm not taking a position on whether or not the infantilism is appropriate, so whether or not I have read the book is neither here nor there.
The previous commenter characterised the text as needlessly infantile. It seemed clear enough to me that they were referring to the jokes about jelly bean stains. I am confused why you interpreted their challenge as being about some approach to problem solving.
> Its is possible that the approach will help you in understanding other things as well.
This is either such a general statement that it isn't worth saying, or it is direct condescension which I don't appreciate.
Yes, I was talking about the jelly bean stain stuff and the cartoons. I don’t see the point.
(I do also think the format of these books is pretentious and not actually that sound didactically, but that wasn’t what I was referring to when I said “infantilizing”.)
I've always seen a sense of humor as an essential component of problem solving. Stressy, serious, businesslike modes tend to get stuck in the weeds and miss the forest etc
It isn’t an essential part of problem solving. I think the fact that you think any technical material that isn’t humorous is automatically “stressy” may mostly say something about you… :\
For what it’s worth, I do have a sense of humor. Harvey Birdman is one of my favorite shows. The Sebben and Sebben employee orientation video is on another level.
I've been saying and feeling this way for quite a while.
For example, someone wrote a book on Kafka streams for kids. It just dumb founded me that someone created it for that audience. The audacity to suggest that kids should learn about that/have something for them. It's a bit weird and doesn't teach lessons outside of the book material.
>>It's a bit weird and doesn't teach lessons outside of the book material.
Actually introducing some of these concepts in an abstract sense can help the kid appreciate subject at hand, and initiate them into more serious study.
Imagine telling a kid they could use a bunch of their friends and using map-reduce to count all the dogs in a park(send each to a section in the park, ask them to count the dogs[map], add all them at the end[reduce]).
Many of these concepts can get kids excited about STEM which is good!
Well for a lot of reason. Firstly they pay better. Secondly, we want more and more kids especially women and marginalised communities to participate more in STEM. Giving them early exposure to things helps.
Also STEM education in general contains useful life skills to have. Having working knowledge of Math, and being able to reason rationally in general can help you in financial things later in life.
We aspire to have a populace with scientific temper.
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.
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.
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:
- Continuous Delivery by Jez Humble and Dave Farley
- The Pragmatic Programmer by Andy Hunt and Dave Thomas
- A History of Modern Computing by Paul E. Ceruzzi
- Version Control with Git by Prem Ponuthorai and Jon Loeliger
- 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?
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?
Check out "Code: The Hidden Language of Computer Hardware and Software" by Charles Petzold. It goes back to the earliest days of computation (Charles Babbage, etc.) and then shows how it evolved into computers we have today.
It doesn’t talk about programming language history a lot, but shows how assembly works.
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?
Most of these aren't directly about any specific technology, SICP itself containing general programming concepts but using Scheme being an exception. The Phoenix Project and A Philosophy of Software Design are good examples of my point, absolutely nothing in them is technology specific. TPP is about project management and organization more than software, just written in a context of IT system development. Philosophy is about developing software more directly, but while the examples are in Java nothing about it is tied to Java specifically.
“This book is a must-read for any serious software engineer.”
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. :)
I tend to interpret these as not "if you don't read this, you're not a serious software engineer", but rather "if you're a software engineer, you are more likely to enjoy this book".
Those comments always come off as extremely pretentious to me. There is not a single way to be “serious" and anybody telling otherwise just has a big ego...
Not only pretentious, woefully unhip. SICP was popular on HN for as long as the site has been around, everyone knows it's worth reading. pg wrote an Amazon review about it in 2000.
I have worked through much of the SICP book, and loved it. I think the author is just trying to emphasize that it's a really great book. Not that it's some sort of initiation that you must go through before you're a "real" software engineer.
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...
- Structure and Interpretation of Computer Programs
- Computer Systems: A Programmer's Perspective
- The Algorithm Design Manual
- Mathematics for Computer Science
- Operating Systems: Three Easy Pieces
- Computer Networking: A Top-Down Approach
- Readings in Database Systems
- Crafting Interpreters
- Designing Data-Intensive Applications
Other books I've seen:
- Computer Graphics From Scratch
- Haskell Programming From First Principles
- Zero To Production In Rust