- 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
https://www3.cs.stonybrook.edu/~skiena/algorist/book/errata
https://www3.cs.stonybrook.edu/~skiena/algorist/book/errata-...
* Database Internals (https://www.oreilly.com/library/view/database-internals/9781...) - very recent and of manageable size
* 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.
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.
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.
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.
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.
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.
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".
[0] https://notes.eatonphil.com/books-developers-should-read.htm...
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.
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.
Examples: [0] https://d1.awsstatic.com/architecture-diagrams/ArchitectureD... [1] https://chipsandcheese.com/2022/11/05/amds-zen-4-part-1-fron... [2] https://people.freebsd.org/~gallatin/talks/euro2021.pdf
I feel like it would make a great movie a la The Big Short.
The academic paper in the appendix is super useful as well.
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.
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 reality is basically not like any other company (except maybe 2-3).
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.
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.
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.
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.
... Using Predicate Calculus.
I said the same thing here: https://news.ycombinator.com/item?id=34206888
We Dijkstra fans have to stick together :-)
I've written a longer review of it here:
https://henrikwarne.com/2021/07/12/book-review-a-philosophy-...
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.
.
.
.
.
.
.
.
NOW GO CONS SOME CAKE ONTO YOUR MOUTH.
A more detailed review here:
https://henrikwarne.com/2022/06/19/effective-software-testin...
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.
- 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.
It doesn’t talk about programming language history a lot, but shows how assembly works.
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. :)
