A Philosophy Of Software Design by John Ousterhout comes with a great way to look at how to design software modules. Found it by recommendation here on HN.
On the programming side:
* Thinking Forth by Leo Brodie
* Lisp In Small Pieces by Christian Queinnec
* Compilers (the Dragon Book) by Aho, Sethi, and Ullman
* Smalltalk-80 (the Blue Book) by Goldberg and Robson
But on the non-technical side, the book that probably had the biggest impact on my career was "What Color Is Your Parachute" by Richard Bolles. It is what convinced me I could transfer my skills from video game dev into another field and how to come up with a plan to do so.
Ill mention a few books and how they've helped me become a better programmer.
- Structure and Interpretation of Computer Programs: this helped me understand the different types of recursion; how a problem can be modeled for the code to solve and how those designs can evolve and how the paradigm I'm using (functional or OOP) can help me
- Refactoring: this book helped me understand the different patterns we can use to alter code. Giving them a name and symptoms is a great way to apply and communicate with other coders. I recommend this book to everyone.
- The little Lisper: this really helped me get recursion. Like really. Although I could use a refresher.
- Clean code: look... this book is bad. Like, really bad. But, at the time I read it, and in the languages I used (Python, C, R) we didn't have many rules on how to write and organize our programs. And I wanted to improve on that skill. And this book gave me pointers and made me think about those ideas. I don't recommend it around, because for many people Clean Code can become a dogma really easily. But if you can question and critique and reach out to other resources and is an advanced beginner to coding, I can see this book bringing value.
- An Elegant Puzzle and Staff Engineer by Will Larson: those helped me get clarity on the role of the technical team in an organization. A team that produces code as the main driver of impact in a product/service. I lump them both because I read them back to back and don't remember, exactly, which is which. But une is more focus on a tech leader and the other a tech specialist.
- Unix and Linux System Administration Handbook: whenever I need to interact with some unix technology, this book delivers in terms of giving me a nice historical view and presenting the common tooling around the tool. This helps me interact with stuff programmatically much better. Be it GRUB, X, SAMBA, this book gave me the necessary introduction I needed, much more organized and thought out and with useful references than the average blog post you will find in the wild.
And I'd like to recommend this Ask HN on problem solving books
As a backend engineer, I've always thought building decent-looking UIs would be beyond my abilities, until I read Refactoring UI
My first learning on data structures came from https://www.amazon.com/Definitive-XML-Schema-Priscilla-Walms...
Not a book but I learned what not to do and what to avoid in my earliest days of programming from the super opinionated tool JSLint.
This was my go to reference to learn CSS https://www.amazon.com/CSS-Pocket-Reference-Visual-Presentat...
As for language design I am mostly self taught through a lot of trial and error. For me it’s all about functions and variable scope. After that everything else is just a statement, expression or a data structure. With that I can write just about anything, make it scale, and keep it super simple to read.
None. The best way to get way better at programming is to work on code bases written by people that are much more skilled than you. You cant learn math by purely reading a math book, you have to work the exercises. Go find an expert code base on github and hack on it, or work at a company on a team with very high programming standards
Well, not exactly a book and not necessarily something I recommend everybody reads, but when I was getting started (early 80's) I purchased a copy of the source code to HDOS, the HeathKit Disk Operating System (written by J. Gordon Letwin, who went on to work on IBM's OS/2). I spent many months poring over every line of 8080 assembly language code in that massive set of bound photocopies of source code printouts. The OS itself, device drivers, command shell, assembler, BASIC interpreter...everything was there. I don't think anyone can realistically do the same thing on a modern system but that experience taught me so much about programming and software engineering.
From non-university stuff, I did not read the book but I read the derivative works and applied it to my life: Getting Things Done. Specifically, Inbox Zero changed my life and made me a better programmer by having me become way more organized and on top of everything.
The Mythical Man Month by Fred Brooks
Refactoring by Martin Fowler
System/370 Principles of Operation by IBM
The best programmers aren't ones who have memorized how to do stuff based on read materials, the best programmers are ones who can look at any piece of software, from a front end application, to embedded microcontroller, and know exactly how to recreate it.
There is a reason why electrical/computer engineering graduates tend to outperform CS graduates in both general skill and the job market. If you understand how computers do the stuff they do, and can think in that manner, thinking in higher level abstractions becomes very easy.
Programming Pearls by Jon Bentley comes to mind. Loved it when I read it and opened my mind to a new level of programming
97 Things Every Software Architect Should Know. Hands down. I just came across A Philosophy of Software Design and it looks good, but I haven't finished it yet.
My experience has been that 'programming' is largely about learning best practices, single responsibility, modularity, writing efficient, clean code. There are no real special books necessary for this, just read the industry standard recommendations.
But if you want to set yourself apart from others you need to study software design and architecture, and follow the big industry names on social channels. Designing software is more of an art and figuring out how to do it isn't immediately obvious or easily attainable from books. It takes years of experience and wide reading, and a lot of what I've learned about it has come from social media, not books.