The engineering books I'd read first, and how I actually get through them
A Blind post listed 9 books for a >600K/yr engineering job. I've read 8 of them. Here are the ones I'd read first, and the habits that get me through books.
A while back someone on Blind posted “Read these books if you want to make >600K/yr”. They said they read these books over the past year to prepare for interviews and got multiple offers from HFTs in the 600-750K/yr range.
Here’s the list, grouped the way they had it:
- Distributed systems: Designing Data-Intensive Applications, and Distributed Systems: An Algorithmic Approach
- Concurrency: Operating Systems: Three Easy Pieces, and Is Parallel Programming Hard…
- C++: Professional C++
- Algorithms: CLRS, and Graph Algorithms
- AI/ML: Introduction to Statistical Learning in Python, and Designing Machine Learning Systems
Having read 8 of these 9 over the last 10 years, I posted a thread on what I’d read first, without getting distracted, if you want to become an actual value multiplier engineer. This is that thread, plus an older one of mine on reading habits.
The one I haven’t read is Designing Machine Learning Systems by Chip Huyen. My order below has five of the nine.
The five, in order
What you get out of them
IMO, going through these books is less about prepping for high-paying roles and more about becoming a better engineer.
Each book gives you a piece of the puzzle, for understanding tech and for applying it creatively to real problems. Technical skills are only part of it, though. How you communicate and work with your team counts too.
Even the Blind poster said as much: read all of these and interviews get super easy from a technical point of view, then it just depends on your communication skills. They also said the books make you a better engineer, period.
How I actually get through books
That’s a lot of pages, I know. Last year I posted my reading list for Q1’2023 (the shelf photo at the top of this post) along with the habits that help me crush my reading goals.
Block time every day
Set aside time for reading daily. Doing it consistently is what turns it into a habit. I read before I start work, in a blocked slot of 15 to 30 minutes every day.
Keep the goal small
Decide how many books, articles or pages you want to read in a given time, then break that into small milestones so you stay motivated. I try to read 15 pages minimum. Daily.
Mix it up
Read across genres, authors and formats so it doesn’t get stale. Go for heavy stuff, but enjoy lighter reads too. I picked up “How to Stop Time” after reading “The Gene”, and both are sitting on that shelf.
Write down what you took away
Jot down key points, new words and your own thoughts as you read. Summarising in your own words helps it stick. I like to journal the key insights from each book as a quick summary.
Talk about it
Discuss what you’ve read with friends, family or online communities, because talking it through deepens your understanding. r/books is a good starting point.
When someone asked me which books a beginner should read, I said that’s such an open question. Tell me what genres you like and I can suggest something to start with. If you’re an engineer, though, start with the five above.
1 of 5 · Distributed systems
Designing Data-Intensive Applications
Opening DDIA felt like stepping into a new dimension of distributed systems. I got a lot of technical knowledge out of it, and on top of that it showed me the bigger picture.
This book is a cornerstone. If you want to understand or work on systems where scale and reliability are must-haves, start here!
2 of 5 · Algorithms
Introduction to Algorithms (CLRS)
Ah, CLRS! The quintessential tome for any software engineer, and a long walk through the land of algorithms.
I kept going back to it while preparing for my interviews and found something new every time. Those sessions brushed up my algorithms for the interviews, sure, but they also made me a better problem solver, and I approached every coding problem differently after that.
3 of 5 · Concurrency
Operating Systems: Three Easy Pieces
Concurrency has always both fascinated and intimidated me. This book was my guide through that murky subject.
I used to think of operating systems as just another layer of software. OSTEP showed me how elegant and how complex they really are. It also helped me optimise a critical piece of our codebase and cut latency significantly.
It takes hard concepts and makes them easy to follow, and more importantly, easy to apply.
4 of 5 · Concurrency
Is Parallel Programming Hard, And, If So, What Can You Do About It?
If you want to go deeper into concurrency after OSTEP, here's another one, and it's free on arXiv.
The author says it's there to help you program shared-memory parallel systems "without risking your sanity", and he wants you to treat it as a foundation to build on.
5 of 5 · Algorithms
Graph Algorithms
This was the natural next step after CLRS. Graphs came up for me in interviews and in real work, and this book goes deep on them.
It's a good reminder that specialised knowledge is often what cracks a hard engineering problem.
Keep reading
Reading notes: Psychology of Money, Deep Work and two more
What I took away from The Psychology of Money, a second read of Deep Work, a Mark Manson passage on victimhood chic, and my weekend pick, Ego is the Enemy.
Reading Petzold's CODE as a book club, one Saturday at a time
Six months of Saturday sessions reading Petzold's CODE together, from flashlights and Morse code to operating systems. Over 120 started. 4 of us finished.
The Redis Paradox: my DelhiFOSS 2.0 talk at IIT Delhi, written up
The written version of my DelhiFOSS 2.0 talk on Redis beyond caching: a short history of caches, live driver matching with GEO commands, and Pub/Sub.
Leave a comment