# Technical Books

## Technical Books

This is where you can learn about what I am currently reading and what I read in the past. It is also a placeholder for my reviews and thoughts on each book I have on my shelf. I am usually very picky about the books I buy, so you'll find most of my reviews to be mostly positive, except on very rare occasions.

• Advanced Programming in the Unix Environment - The UNIX / Linux bibble. System calls, libraries and other interfaces that work together to bring the power of Linux to a machine are all listed here. The book is about programming in C, but it's also a great resource to learn about the UNIX philosophy and system administration. What is a filesystem? How is it organized? How does it work? How is I/O implemented? What exactly happens from the moment you press the power button until bash is running and accepting commands? This book has evolved over the years and gained a lot of attention; it is a great reference manual for experienced programmers.

### In the past

If you're deciding whether you should buy a specific book, you can check this list of books that I read in the past and learn from my experience. For each book, I provide a quick review. The listing is in chronological order; books on the top of the list are the most recent reads.

So far, I loved every technical book that I've read. Oops - that's not true anymore. I've had my first bad experience. I have been stumped by a crappy technical book. Well, that's life!

• Data Structures and Algorithms Made Easy [Narasimha Karumanchi] - DO NOT READ THIS CRAP. It's a waste of money. Don't buy it. This book shouldn't exist and everyone who has ever bought it should get a refund. I haven't even read the whole book, I was afraid to - it has a lot of wrong information, so I completely lost confidence to learn about other topics. Common misconceptions are all over the place. I'll give you some examples: the very first page on Chapter 1 says this: For example, int may take 2 bytes or 4 bytes. If it takes 2 bytes (16 bits) then the total possible values are -32768 to +32767 (-2^15 to 2^15-1). The first mistake is an unfortunate typographical glitch: the line breaks between the - in 32768 and the "3" - what a terrible place to insert a line break! But more important than that, this is plain wrong. The author makes it look like 16 bit signed integers always span that range, but that only happens if we assume 2s complement representation. Sure, it's very common, but there are other possible representations. A programming book must be precise. But that's a minor issue. This is about to get serious. A few pages ahead, the author shows a diagram where he shows that $$\mathcal{O}(n)$$ is worse than $$\mathcal{O}(2^{log(n)})$$, and that's wrong, because $$2^{log(n)} = n$$. Later in the book, when the master theorem is discussed, he solves an exercise with $$f(n) = n!$$, and that is illegal, because the master theorem says that $$f(n)$$ must be $$\mathcal{O}(n^k log(n)^p)$$. In the chapter about recursion, he says that [...] generally, loops are turned into recursive functions when they are compiled or interpreted. WHAT THE HELL?!?!?! Ironically, one page later, he goes on and writes [...] iterative solutions are more efficient than recursive solutions, so the author is basically saying that compilers will deliberately generate slower code by turning iteration into recursion. Cool... By the way, that chapter about recursion consists of 3 pages - my article about mastering recursion is a much more complete resource - and it's free. The linked lists chapter provides wrong solutions for the exercises (the code for problem 5 is wrong, it doesn't work - the right solution is showed in Cracking the Coding Interview). Another thing that bothers me is that problems and solutions are tied together, making it really hard for you not to look at the solution. It's stamped there immediately after the problem description. It sucks. The typeset is ugly and the code is not even written on a proper font - he uses the same typeface to write the text and the code (and it looks like the whole book was written using Microsoft Word? Seriously?!). There are grammar errors (and I'm not even a native English speaker), and the book itself is tremendously huge when compared to others. In short: problems have wrong solutions, information is wrong and / or misleading, and chapters are superficial and short. I do NOT recommend this book. I was astonished at the amount of 5-star ratings in amazon, and I still cannot understand why. This is a terrible resource. Instead, I will try Data structures with abstract data types, by Daniel F. Stubbs and Neil W. Webr, which at least was recommended by Peter Van Der Linden - and you should do the same. Forget that this book exists.

• C - A Reference Manual [Harbison & Steele] - This is the C book. Harbison and Steele really hit the spot with this one. Recommended by Peter Van Der Linden in Expert C Programming - Deep C Secrets, I got my copy of C - A Reference Manual and was amazed at how detailed and rich this book is. C compilers writers have been using this as a reference manual for a very long time. It's a shame that there isn't an edition for C11 (the 5th edition covers C99), but hopefully, this will soon be sorted out. This book is not for beginners, it assumes you already have a pretty decent knowledge of the language, it is in no way an introductory tutorial. Some very neat C issues are presented, and dark topics like trigraphs, compilation stages, preprocessor functionality and how macros are expanded, sequence points, switch usage (an extremely bizarre example of switch usage is shown), what exactly is volatile, and other things, are discussed. The book includes several code examples, and one of the most interesting Set implementation using bitwise operations that I have ever seen. If you have a chance, give a look at the function next_set_of_n_elements(SET x) on page 241, which can be used to solve very elegantly a bit manipulation question I saw in Cracking the Coding Interview. I was delighted. Extremely useful book. Kind of long, but most of the final chapters are reference manual for the standard library, which is nice to have around. I absolutely recommend this to other developers!

• Computer Organization And Design - The Hardware/Software Interface [Patterson & Hennessy] - I've read this as part of an Embedded Systems course. The book is widely known and used in the most renowned universities across the world on computer architecture courses. It contains very detailed information on how a processor works, how it is implemented, how it communicates with other components across a computer, how I/O is managed, virtual memory, and other similar topics. You really go down to the bit level. By reading this book, you will learn about cached memory hierarchies (what is an L1, L2 and L3 cache), different types of processors (superscalar, vectorial instruction sets, ...), how a multi-core processor ensures cache coherence and consistency, how instruction pipelining works and the issues that arise with it, what really means pipelined instructions and how it affects performance, why increasing the pipeline stages can be bad, how to measure program performance, how to improve performance... I could stay here all day long. Oh, and let me say this, because it's important: you will finally understand how to appreciate a CPU. No, it's not just the clock frequency that matters. The general belief that the higher the clock frequency, the better, can be misleading, and lots of people fall for that, even CS students. Boy, there are so many things to compare. To name a few: cache size - really important, and no one knows what exactly is that, and it is often hard to find; cache associativity - important because of collisions; cache block size; instruction set; number of cores; number of threads per core; pipeline stages; power consumption; branch prediction policy - is it static or dynamic? If dynamic, how many state bits?; RISC / CISC; TLB size, well, you see, lots of stuff. You're being naive if you rely solely on CPU frequency, not to mention that it sounds totally noobish. Now, if you go out to a store and try and ask such information to a seller, he will stare at you and wonder if you're crazy. You see, it's all about marketing, people will only care for CPU frequency, so, that's what they sell. With this book, you will learn fascinating and valuable information that make you a better professional. You will learn common falacies and pitfalls. Anyone claiming to be a computer's professional should read this book, it contains extremely important core concepts for those working in this field. I absolutely look at computers with another perspective after reading this, and I finally know how to choose a CPU.

• Programming Pearls (2nd edition) [Jon Bentley] - As the book suggests, just as natural pearls grow from grains of sand that irritate oysters, programming pearls have grown from real problems that have irritated real programmers. This is a general book on data structures, algorithms and efficiency. Trust me, everything you want to know! The book is divided in 3 major parts: Preliminaries, Performance and The product. Several important topics are covered in the field of algorithm design techniques, program verification, performance issues and back-of-the-envelope calculations. I would recommend this book to any programmer willing to master algorithms. This is a relatively short book (240 pages), but take it easy, don't try to read it quickly. Columns are brief but dense, it might take a while to assimilate the concepts. You might need to read a column more than once, and if you're commited to exploring this book, you will take a lot of time doing the exercises (each column holds about 10 to 15 medium / hard exercises). My advice? Don't read the next column without solving every exercise from the previous one. It's a tough rule to follow, and that's why it took me almost 2 months to read this book from cover to cover. You can see some comments on a few exercises in my github repository. See the Code Snippets section. I have also published some articles in here about exercises that I found hard. This is not just "another book on data structures and algorithms". Steve McConnell recommends this book.

• More Joel On Software - Further Thoughs on Diverse and Occasionally Related Matters That Will Prove Of Interest To Software Developers, Designers, And Managers, And To Those Who, Whether By Good Fortune Or Ill Luck, Work With Them In Some Capacity [Joel Spolsky] - The story continues. This book is the continuation of the traditional Joel On Software series. There's some pretty good material in there! Joel did a great job with this book where you learn a vast majority of topics: coding-related stuff, economics, management, how to start a software company, how much should you charge, the importance of the workplace, the importance of user interfaces, and much, much more. With this book, you will learn lots of useful facts about software industry that go way beyond coding, and you get to understand why everything works the way it works.

• Expert C Programming - Deep C Secrets [Peter Van Der Linden] - C, the powerful, simple to learn language where you can create hard-to-read programs or unexpected, hard-to-track, weird bugs. This book shows all the nitty gritty details of C, and provides examples of code with hidden bugs and techniques to find them. This book is very good. Peter worked for Sun as a compiler an kernel developer, and his book is full of scary stories about the most obfuscated bugs. It has some great programming challenges, like writing a more powerful dcl implementation (dcl is a program to interpret C declarations and translate them into English). His refined and constant sense of humour make this book a must-have in any programmer's personal library. You will learn stuff that you don't in K&R. It's a nice complement. For example, you will finally understand why arrays and pointers are not the same thing, and why defining a char a[100] in file1 and declaring extern char a[] in file2 is different from declaring extern char *a. The former will work, the latter will be the cause of an ugly segfault. And did you notice how I wrote define in file1 and declare in file2? It was intentional, these are the correct words. Want to know more? Read the book! Seriously, read it! I read this twice. I love it.

• The C programming language [Brian W. Kernighan, Dennis M. Ritchie] - The good old, classical C bibble. I thought I knew C, until I started reading this and solving the exercises. If you consider that you know C but never read K&R, you really don't know C, you just have a vague idea about it. The trick is not just to read the book. You have to solve the exercises. And I mean really solve and test all of them. You will learn twice as much if you do this than if you only read the book. Solving the exercises will force you to think about small implementation details that you would have never thought of, and it improves your skill. It will make you another person. And don't just solve the exercises "on air", I mean, don't just think about how you would implement it in a high-level way. No. You have to Write Teh CodeZ and test it. That's the only way you will learn something useful. Implementing it in your head will always work!

• Code Complete (2nd Edition) [Steve McConnell] - This is a nice book about high level aspects of software engineering. It's not as code-oriented as traditional programming books like K&R, but a significant part of the book is about good coding practices and styles (where you get to see actual code examples of good and bad programming techniques), how to coordinate coding templates among a team, how to debug properly, and how to be more productive by using the right tools. From a high level perspective, it's a great book that approaches the world of software development focused on teams coordination and management and the life cycle of a product (like design, architecture, construction, testing, quality assurance). Although I read quite some interesting advice from this book (like, for example, understanding why #define cube(a) a*a*a can create hidden, very hard to track bugs, and instead should be written as #define cube(a) ((a)*(a)*(a))), I think that I read it too early for my age. I feel that this book is of great help to someone who has been working on software development for some years and is building a complex product with a big team. From my perspective as a CS student, I think that a great load of what I read in this book about non-technical issues will be forgotten because I simply don't fully understand the importance of these factors yet, and I do not give the appropriate value to this kind of advice because I never actually left college for more than 3 months for summer internships. Would I recommend this book? Sure! It's a must-have in your shelf if you want to be a great programmer.