Disclaimer/Disclosure: These opinions are my own, not my employer’s. I don’t speak for Amazon and they don’t speak for me. The book links below are to Amazon only because Amazon is the largest bookstore, not because I work there. I’ve removed the affiliate link, so the links are raw; no kickbacks.

Table Of Contents

1. Intro: R E A D A B O O K

A quote that’s stuck in my mind is attributed to Lincoln, who supposedly said “Give me six hours to chop down a tree and I will spend the first four sharpening the ax.” Based on the history of such cute quotes, he probably didn’t actually say that, nonetheless the sentiment holds true: there is a lot to be gained by spending an appropriate amount of time “sharpening” versus “cutting.” In this case, the “sharpening” is reading.

I’m a big advocate of programmers reading books. I know that Google, StackOverflow, and GitHub form a Divine Trinity of help for us, but we can just as easily become complacent and dependent on them. They can only help you find solutions to problems you can recognize and problems others have already encountered. Google can’t help you if you don’t know what to even search for or if you don’t even know you have a problem with your 20k line “Helper” class with 0% test coverage.

To put it in RPG terms: Books let us get an XP boost from the author for free and level ourselves up! Just like every civil engineer isn’t expected to independently rediscover concrete, we shouldn’t be approaching programming as a practice in hack-and-slash. It takes less time to really learn git than to read more “git workflow” articles.

This list may look daunting, but only because I give several “OR” options and give several language-specific examples. So for someone starting out, it’s really only a dozen or so books. In fact, if you cheat to the bottom, you’ll see my tldr section, which contains the absolutely most essential books, regardless of your programming language.


I am aware books are not the only or even the best way to sharpen your axe. Online references and documentation are invaluable. Google is free and there for you 24/7. But for those important things that don’t change often with each minor version change, like career advice, algorithms, and Big-O considerations, sometimes an edited page is best. If you just “know” that you don’t learn from books, then this post may just no be for you, but I hope that you’ll give books another chance.

This is all to supplement your other means of self-education. I know the Lincoln quote suggests you spend more time sharpening than cutting, but that not realistic. I’d suggest allocating somewhere around 10% of your work-time to learning when you’re in “steady state” work. If you’re on a new team or project, increase that way up. If you’re about to launch, maybe drop down to zero, but don’t leave it down there.

Paper or eBook?: It Doesn’t Matter. Whichever you prefer and that you’ll actually read.

Audiobook?: Ok, this one matters. I’ve put a 🔊(speaker emoji) next to books that are digestible in audio.

Lastly, my top recommendations are marked with a 💎(gem emoji).

2. Vital Professional Advice

These are the most vital because if you read these, and follow their advice, you don’t need to read the rest of this post. You’ll already be doing what’s needed in searching out new information and honing your craft.

I also call these “vital” because they’re among the most influential books I’ve ever read. I’m not being cliche when I say these books changed my professional life.

  • The Unwritten Laws of Engineering🔊 This is one of the oldest books on this list. Originally meant for mechanical engineers, it provides specific and general non-technical career advice. It focuses on what we call “soft” skills today. This field puts so much weight into technical prowess that we often think of these “soft” skills as somehow beneath the “hard” skills. Nothing could be further from the truth. If you don’t spend time on learning how to navigate your career, you’ll be as well off as a dragster on the backroads: you’ll get nowhere fast. I only wish I could have read this book sooner; it would’ve saved me a lot of trouble early on.
  • Becoming a Technical Leader💎 Like many of these books, don’t let the title fool you: this is not just for people planning on becoming a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this book you must work through the exercises to get the full effect. It will be worth it. It’ll be like having your own therapist, life coach, and mentor, except that it’s just you and a notebook answering very important questions.
  • The Pragmatic Programmer💎 This is really the “genesis” book for this whole list. I consider this book 10x better than Clean Code and Code Complete combined! (Though that may just be because I read PragProg first?) As the name suggests, this book provides more tactics advice but also gives great career advice too. The most famous is to “learn a new language each year.” This kind of advice seems a bit much, but over my career I’ve had to write in over a dozen different languages, even though 90% of the code I’ve written has been in just one language, the ability to pickup new languages quickly and easily is a solid skill to have. And that’s just one particular tip from this book.

3. “Algorithms”

Coding interviews are dumb; like super dumb. And yet, they’re still the best way to prove that you (or the candidate you’re interviewing) knows that a Hashtable isn’t something from the IHOP menu. So consider this book “Defense Against the Dark Arts.” Just make it out of the interview alive and get hired. You can fight the system when you have food on your table. Just listing this book makes me feel gross, but I’d be remiss if I didn’t show the Stupid Secret Recipe to coding interviews.

Algorithms (for interviewing): Cracking the Coding Interview

4. Actually Useful Algorithms and Data Structures

Now that mess is out of the way, let’s talk about real algorithms, not stupid trivia puzzles.

Actual algorithms are important. They’re the difference between O(2^n) and O(n). If you haven’t had the pleasure of reducing a program runtime from hours to seconds, it’s sublime. Try out Project Euler if you’re into it.

Algorithms are what can give you 1000x performance boosts but more importantly, they can help you analyze why and avoid it again in the future.

One tip that pretty much applies to every language is “don’t append to a string in a loop.”

Why is that? Well, because if appending is an O(n) operation, and not O(1), then doing it in a loop is O(n^2). Even though, if you just followed the “loop-counting” method of Big-O notation, you wouldn’t know why.

What I really love about both of these books is the references they give to other implementations. In the real world, if you’re writing grep by hand, from scratch, you’re going to have a bad time.

“But can’t I just google these?” Sure, but how are you going to know that you’re looking for? How would you know you’re looking for the min-convex-hull solution for a directed acyclic graph?

  • Intro to Algorithms CLRS The Algorithms textbook. I put off buying this book because of the hefty price tag, but it sure is nice. It provides such an in-depth and approachable explanation of the most important algorithms and data structures. I especially like how, even though it’s a textbook, you can focus on what you want to learn.
  • The Algorithm Design Manual💎 Of all the books listed so far, I would want to keep this one in my desk. I say “in” not “on” because I wouldn’t need it often. When you do need it, it could be a project saver. It has incredible descriptions and guiding questions related to algorithms (e.g. “Are the edges directed?”). Some algorithms are in-text in readable C and all are online algorist.com. Your team should have at least one copy among you. I always keep a copy of the source code on my local machine for reference as well.

5. Pocket References & Guides

We’re departing from the “big picture” books and coming down to earth to my personal ace in the hole: O’Reilly Pocket Guides and References.

I want to be clear that these tiny books have nothing that you couldn’t find online for free. And yet, I still find them worth it. How does something beat “free”? Well, if it adds value and convenience that’s worth the $10.

Each of the pocket guides that I’ve bought have been worth it solely because they distill and filter the knowledge to what I will most-likely need, while giving references to what I might need later.

Their size makes them perfect for reading between builds, on the bus, or while drinking your morning coffee.

I give some of my favorites below, but my special favorite has been the Git Pocket Guide because it really teaches git in such small space. I’ve worked with Git for 7+ years and am usually the “Git guy” on my team, but the Pocket Guide really felt like a level up.

No matter how long you’ve been writing in a language, it’s never too late to pickup on a pocket book for it. You’ll learn something and if not, then pass it onto your next new-hire.


6. Every Language Has One

Finally, we have the books that most people think of as “programming books.”

I like these because they provide a few advantages:

  • High-quality examples of working code
  • In-depth look into the language
  • Comprehensive tutorial
  • Examples of idioms & style
  • Language design and considerations
  • Tractable Questions

It’s more common for new languages to have tutorials as part of the languages website, but that’s still uncommon.

More often, if you try to search “how to learn language x” or some similar query, you get flooded with the languages library reference and thousands of mostly terrible introductions.

Consider when your time is worth more than your money or at least determine what that cutoff is. Consider that when you’re first learning a language, it’s hard enough to maintain the discipline to do strictly that, much less that and do the legwork of finding good material.

I’m not saying to buy every book on the language; in fact, my rule of thumb would be no more than 1 book per language per year. Especially wait on the “Effective” books until you’re at least familiar with a language, or the tips will be too over your head. (Please break this rule when you’re starting a new job and need to get up to speed on a new language).


7. Intermediate to Advanced

Finally, with a solid foundation in your career, basic relevant computer science, and your primary language, what’s next?

Well, lots actually. Our knowledge pool runs ever so deep.

I’d caution against reading further until you have a couple of years under your belt. Not out of some “hard knocks” mentality. It’s so that you will have seen enough problems to know where the solutions apply, rather than having a quiver of solutions itching for a problem.

First, you’ve got general code quality and patterns. Not to spoil them too much, but the “code quality” books are basically just Test Driven Design in disguise. You’ll find that being able to work with code, whether it’s “legacy” or not, all comes down to tests. If you don’t have tests, your code is brittle. It doesn’t matter how recently it was committed, it’s already legacy if it doesn’t have tests.

  • Working Effectively with Legacy Code💎 I really wish they hadn’t put “Legacy” in the title. This book is just as relevant on day one of a project as on day one-thousand. I have literally had junior developers ask me questions that are literal chapter names in this book; it’s eerie.
  • Refactoring This book is honestly mostly outdated by modern IDEs, but for languages that don’t have Enterprise-Level IDEs, this is handy.

Second, as you progress as a developer, you’ll notice patterns in code, particularly in the design of object-oriented code. We call these, well, design patterns.

I’ve seen some inane behaviors around design patterns, like having to use some number of them in your code to get promoted.

At the core, just remember: they’re just names given to common patterns. They’re not something to code toward (over-engineering) but you shouldn’t be rediscovering them either (under-engineering).

Some languages can avoid them altogether with metaprogramming like Ruby or via macros like Common Lisp.

Finally, the major shift into a “senior” engineer or “tech lead” role is all about meta-work: work that deals with work. In simple terms: project planning.

Herein lies paradoxes, like:

  • deployments on Fridays are a sign of extreme risk or extreme confidence
  • being a “rockstar/cowboy/ninja/superhero” developer means you’re actually doing your job poorly
  • adding developers to a late project only makes it more late

DevOps and Project Management: The Phoenix Project🔊 The Mythical Man-Month

8. Bonus Categories

Skip this section if you want to be broke and miserable.

I’m only half joking, if you don’t know what “finances” are or what “philosophy” has to do with the real world,” then yeah, you probably will be a bit broke and a bit miserable. To be fair, you can still be broke and miserable no matter what, so that’s not a good argument either.

I can’t generalize here, but I’d like to say that most software developers make decent money, or at least a livable wage, or some money at all. Either way, you need a plan for that money, no matter how much or little it is.

The good news is that you don’t need to spend much (or really ANY) money to get educated on basic personal finance. I’ll let the source below speak for me, but know that it’s no cliche that when you get your money managed, you’re giving yourself a raise.

If you have at least two brain cells, you should be asking yourself “What am I doing with my life?” at one time or another. or “What does it all mean?” or “Am I happy?”

Our work is often isolated, the compiler is brutally logical while the browser behavior manages to be absurdly illogical, we put in hours of work to move some bits around, and for what? We make our company $10X dollars so they can pay us $X. And yet we love it. The thrill of problem solving using knowledge hard-earned over years or decades. Collaborating with sharp co-workers and seeing junior developers mature and surpass us.

I think that because our work is generally more introverted (we work alone more often than not) and cerebral (we work more in our brains than in our hands), I feel like developers can benefit from philosophy. (Spoiler: so can everyone!).

I personally follow a custom potpourri blend of Existentialism and Stoicism with plenty of “miscellaneous”

9. Tips for Frugality

Books can be expensive, especially some of those listed. Here are some quick tips on how to read more on a budget:

  1. Support and visit your local library
  2. Ask coworkers or local meetup groups to borrow
  3. Browse used book stores and/or craigslist
  4. Older editions are usually good enough if they’re within 4 or so years
  5. The kindle program is free and kindle ebooks are usually cheaper than paper
  6. Ask your manager if the company would fund a “Developers’ Bookshelf”
  7. Some books have been published online as PDFs, though you’re on your own there pal ;)

10. tldr: Top Recommendations 💎

In several categories, I tried to give a couple of good options, so you could chose based on your own judgement.

Please note, that this whole post was already cut down from a larger list of books. I still stand behind all of my recommendations above, but making Top X lists is fun.

So here are my top 6 books I’d recommend for any software developer:

What are your book recommendations? I’d love to hear them in the comments.

Any books you would recommend against? I’m planning on making that post next.

This post is also available on DEV.