A black swan is a highly improbable event with three principal characteristics: It is unpredictable; it carries a massive impact; and, after the fact, we concoct an explanation that makes it appear less random, and more predictable, than it was. The astonishing success of Google was a black swan; so was 9/11. For Nassim Nicholas Taleb, black swans underlie almost everything about our world, from the rise of religions to events in our own personal lives.
I have listened to the audio version of “The Black Swan” twice. First time at the beginning of the year and the second time just recently. The book is philosophical in a way. It is not very easy to fully comprehend conveyed message as author frequently diverts to fictional stories, terms in French, and thinkers that are long time dead.
There were two striking statements in the book “anyone can be a president” if someone like “these people can get a Nobel prize”. Sounds actual? Think of Trump vs. Clinton presidential race and Bob Dylan receiving Nobel prize in Literature if you are not reading this in Autumn 2016.
This does not mean that Nassim Taleb is any sort of predictor or prophesy maker. He himself says that he cannot make predictions, instead he highlights over and over again that rare events that seem improbable do occur more frequently than most of us would imagine and at the same time it is impossible to come up with mathematical models that would somehow calculate probabilities for these events. Unfortunately, we cannot know what we don’t know, therefore the best strategy for any of us is to build robustness to black swan events.
Application of the ideas expressed in the book is very wide. Starting with building financial portfolio consisting of 90% of very safe investments and 10% of extremely risky ones, therefore exposing yourself to probability of catching a black swan, like Google or Facebook. Ending with applying it to your life by exposing yourself to variety of endeavors. Careful here: event’s consequences are even harder to predict than occurrence of such events.
There is one aspect of the book that I don’t like. The author almost throughout the book despises other people imagining them as aggressive apes and suggesting nasty things like putting a rat down someones shirt. I do not exclude that he imagines his readers in the same way: silly monkeys reading higher caliber philosophical work. This, though, does not disqualify his book from being a really valuable contribution to human knowledge, but, in my opinion, it is only thanks to the black swan event of him benefiting from the 2000 crisis that made him successful and subsequently allowed him to write this and other books.
This book is definitely worth reading. It may make you look at the world as sequences of improbable events that change everything around. It could also make you way more skeptical about the theoretical modeling suggested by economists and other tie wearing experts. The book is not an easy read. On the contrary, it requires a lot of attention and thinking. Maybe leave it for a time when you are in a “philosophical” mood.
I read this book because of the recommendation I found online. It was in one of the Bill Gate’s reading lists. Maybe this post will have same effect on you… and you will decide to pick it for your reading.
“They say there are no stupid questions,” the author writes. “That’s obviously wrong. . . . But it turns out that trying to thoroughly answer a stupid question can take you to some pretty interesting places.”
Indeed, I remember we had a lot of hypothetical scientific discussions with my friends during my university days and these discussion would just go on and on ending sometime around 2AM. It was a lot of fun diving deep and exploring every possible twist. You get to have same fun when you read the book.
Well… it is actually more fun to read the book, since it is very nicely illustrated and thoroughly researched. Basically you don’t get to read rant – everything is cross checked with scientists by Munroe.
I guess this book also teaches to approach problems that require scaling, approximation, simplification, calculation, estimation. It also helps to understand physics better. And if you have some silly question that keeps you awake at nights you can always submit it on the xkcd web site.
This book is pure entertainment and joy. I can surely recommend this book to anyone generally interested in science.
The book “Coders At Work” is a collection of interviews of famous coders. The book takes a reader through 15 career stories. It inspires and gives insight into minds of great programmers.
Most of the selected coders are of older generations, so at times, it is hard or, rather, not exceptionally interesting to follow some of their career endeavours. Especially, if the whole career was around one system or one language that is “dead” today (think of COBOL, Fortran, PDP-1, etc). I don’t mind to know the history of the industry, but I’m not interested in too much of the details (you can blame me if you wish). On the other hand, it was very interesting to try to understand how these people think and how they approached problems they had. I really believe there is a lot to learn from them.
The author, Peter Seibel, starts interviews with a usual but interesting question about how the interviewees got involved in programming. Then, the author proceeds to questions that relate somehow to what interviewees have done in their careers. There are standard questions about debugging, favorite editor, opinion on some programming language, and other.
I liked answers to the question on how they hired people and what advise they can give to the young programmers.
There were a couple of questions that I didn’t like. One was “Do you consider yourself a scientist, an engineer, an artist, or a craftsman?”. I think it is a pointless question. These nouns can be interpreted in different ways and any answer would be just fine.
Throughout the book there was a discussion about the importance of computer science education and one of the questions was if interviewees have read the book “The Art Of Computer Programming”. It was kind of introduction to the last interview with Donald Knuth. I liked the interview with him, but I’m not sure if the author had to put so much emphasis on this personality.
The list of interviews is available at book’s website with short descriptions of who those people are and what they did. To be honest, before reading “Coders At Work”, I only knew about Douglas Crockford, Joshua Bloch, and Donald Knuth.
The book gives insight into how some of the great programmers achieved what they have achieved. It educates and inspires, though some of the stories might not be very exciting. At times, you may think that other big names would have made the book even more interesting. Nevertheless, I liked reading the book “Coders At Work”.
“Release it!” is an excellent book that makes you and your application prepared for the harsh world of production. It talks about all kinds of things related to the most important part of development lifecycle – releasing your product and keeping it alive.
The book consists of four parts, introduced by interesting case studies, like one unhandled exception that costed an airline a day of nightmare and tons of money.
Let me list some of the keywords from the book for better idea what the book is about:
Things that I really liked about the book:
There is a really nice strategy explained on zero-downtime. One, that especially boggles me, was approach related to database upgrade process for zero downtime. The strategy is relatively simple: 1) you extend the system/db and add some bits and pieces so it is backwards compatible, for db it could mean new nullable columns and triggers to fill-in data, 2) you roll out, 3) you cleanup. Easy!
Not so great things about the book:
The book will be most useful for developers of large enterprise applications, especially where downtime costs real money.
But, in any case, I would highly recommend any developer, and deployment engineer for that matter, to read this book!
There were few not so technical books that have made it to my technical reading list last year. One of those was a book called “The Design of Everyday Things”. It can probably be considered a classics for designers, it is also helpful for software developers who do some UI. But it doesn’t harm to read the book even if you have nothing to do with designing anything as it allows to understand how things are designed and why in many cases designer is there to blame and not you when something isn’t working as you were expecting.
For starters, have you even been in situation wondering how that damn thing is working? It could have been a microwave impossible to open or a complicated ticket machine in some country or software written by “lousy” software developers. Just look at the kettle on the book’s cover. Any ideas how to pour water with this kettle?
The book brings many show cases for good and bad design (somewhat dated, though). It explains what a good design means and what are constraints designers have to battle, like time, price and not the least look and feel.
Recently we found out that one of our old applications is not used by users because it is too complicated. At that same time, if used, it could save hours and hours of manual work. It is on our roadmap to rewrite this app, but at least I will have more gear in my tools belt.
I don’t think this is a required reading for software developers, but it definitely enriches your outlook. As a bonus you cal explain your co-workers why a tap in a kitchen is designed is a such and not a different way.
But because, JS is the language so popular and where it is so easy to start without reading anything, this is how most of developers start. This ends up in painful discoveries, gotchas that took ages to come to and production bugs no one knows how to reproduce.
Earlier this year I went to a conference where Douglas Crockford had a key note. I decided, I’ve got to read his book on JS.
I think if Douglas had only left the good parts of his book then it would be a really great even shorter book on JS.
Most of the book are good parts. I really liked explanations behind certain language behaviour and design decisions. Especially, I liked Appendixes A “Awful Parts” and B “Bad Parts”
In my own opinion, not so good parts are: pointless Shakespeare quotes at the beginning of chapters, redundant code in examples like a loop for creating cat doing ‘r-r-r-r’, few places where something non-JS specific is explained like RegEx, few places where something self-centric was mentioned like “Beautiful Features” chapter.
It is a really good book, but if you have few years of experience in JS and some more in other languages you will find very little to learn from the book.
The book is written by Jon Skeet (the guy Number One at StackOverflow) and is a purely about the C# language. It distances itself from the .NET framework and libraries supplementing the framework.
Structure of the book follows C# language versions. This isn’t particularly useful if you are trying to learn the language by reading this book after some other introductory book. But for software professionals, though, it could be a joy, since it takes you through your years of experience with the language. It tends to remind you about times when something wasn’t possible and later it became possible. Kind of nostalgia, I would say.
First chapters could be somewhat boring. I read the book cover to cover, since I didn’t want to miss on anything, but probably it isn’t the best way to read the book.
Jon is very pedant when it comes to defining anything. This, of course, is double sided: very good when you have strong knowledge and understand components of the definition, but, unfortunately, it complicates understanding. There were some places in the book which I had to read few times to completely understand. Just for instance, in a chapter about Covariance and Contravariance:
[…] the gist of the topic with respect to delegates is that if it would be valid (in a static typing sense) to call a method and use its return value everywhere that you could invoke an instance of a particular delegate type and use its return value, then that method can be used to create an instance of that delegate type.
On the other hand, I found it very important that details are not omitted. I was reading the book for the depth of it. So details and preciseness is exactly what I was expecting, even though they come with the price of slower comprehension.
You may have different background than I do, but if you are a .NET developer with some years of experience, chances are the only chapters with new and difficult information will be those that are not reflecting everyday practical usage of C# language. For example, all of us use LINQ these days, but very few of us would need to know how it works internally or need to implement their own LINQ provider. Very few of us would dig into DLR or how async/await is working.
Almost in each and every chapter there was something where I could add to my knowledge. For me the most important chapter to read was “Chapter 15. Asynchrony with async/await”, since I have very limited experience in this feature.
In my opinion, the best two books ever for C# programmers are “CLR via C#” and “C# in Depth”, meaning that I just added one to this list.
“C# in Depth” is a great, precise, and thorough book to complement and enrich your knowledge.
I highly recommend reading it.