This book is basically a coverage of all the major features of the C# language that have changed since the first edition of C#.
It is a pretty long book, but it covers a pretty large topic and it does indeed cover it “in depth.”
I debated whether it was worth my time to read this book, since I already had a good grasp of most of the C# language, but I am definitely glad I did. There are many very detailed concepts that Jon does an excellent job of explaining which make other language concepts seem much simpler.
The book is basically a forward progression through the advances of C# through each major revision. Jon does an excellent job of presenting not just the what, but the how and whys for each language revision.
The developer that has at least a decent knowledge of the C# language will get the most out of this book, as it can get a bit tricky and complex at times. Definitely is a book for advanced developers as well, who will most assuredly learn something about the language they didn’t know.
If you’ve watched any of my Pluralsight courses, you know that I like to teach in a very informal and conversational way, and it seems Jon Skeet also takes this approach and makes this highly technical book quite readable.
- Very excellent and detailed coverage of language features of C#.
- Excellent verbal illustrations to help simplify some complex topics and make them memorable.
- Down to earth conversational approach to the material makes it a joy to read.
- The coverage on LINQ is phenomenal.
- Book builds in progression on previous examples and chapters very naturally.
- It is very obvious great detail went into making and planning out this book. Rare to see today.
- Coverage of dynamics and DLR is a bit dry. The topic is very complex and I felt like the book launched in a bit too fast.
- Sometimes I felt like Jon was a bit too objective in presenting his opinion. I generally trust the values and opinions of a skilled developer like Jon Skeet, so I would rather have his opinions be presented a bit more firmly in the book.
What I learned:
First off, a whole lot more than I would have expected.
There are many aspects to the C# language that I thought I understood fairly well, but had never turned down one dark little corridor. This book made me turn down those corridors and face the demons there.
Specifically, I thought I understood how LINQ providers worked. I never really looked into one, because I had an assumption about how a LINQ provider would work based on what I knew of the language. I found out that I was wrong in my assumptions and I now have a much more thorough understanding of LINQ and how all the pieces of the language fit together to make it work.
I also learned quite a bit about dynamics and the DLR. Although it was a bit painful, I felt like the book got me to reconsider my stance on dynamics just a bit and consider some places in the statically typed C# language where they might make sense. (Understanding how dynamics work reduced them to the same level as any reflection based code in my mind.)
Overall, I would highly recommend this book. My only two negatives about the book should not dissuade you from reading it. A beginner or intermediate C# developer could easily raise both their skill level and knowledge of C# considerably just by reading this book, and any advanced C# developer should have plenty to learn from it as well.
So I’ve had Enterprise Integration Patterns sitting on my bookshelf for quite a while now. I had skimmed it a few times, but never really gave it a read.
It’s a hefty book that you could definitely use to cause some major kidney trauma to an unsuspecting DBA if you sneak up on him from behind and jab the pointy end of the book into his unprotected backside.
I finally got around to reading this because it is one of my last remaining analog books. It is part of my quest to cleanse my life of all possessions that are not digital or are not monitors.
This book is really about messaging. Don’t let the title fool you. Definitely consider picking up this book if you want to use a messaging platform like BizTalk, MSMQ, or JMS to integrate several applications together.
- This book is extremely detailed about each messaging pattern, when to use it, and how to implement it. If you are seriously going to consider implementing a messaging solution, you need this book. Honestly, I have done some messaging without it and now that I have read it, I feel like I really missed the whole point before.
- Multi-language / technology. This book is generalized enough to not push you in a language or technology decision, but has specific examples in Java and C#.
- Simple to understand. I was rushing through this book because I wanted to get through it and I found that I was picking up pretty much every concept being thrown.
- Excellent reference. I can see using this book in the future to go back and solve some sort of problem dealing with messaging.
- Broken down into perfect size pieces. If you read this book, you should have all the tools you need to solve any kind of complex messaging scenario. By thinking of messaging in terms of the patterns or blocks in this book, very complex problems become much simpler.
- It is freaking long. Seriously. This is a long book. It has some diagrams and some code, but it is long. Get ready for an adventure.
- It’s a little dry, probably because it is so long. Some of the code examples are a bit repetitive, and no one ever wants to see XML soap bindings on pages in a book.
What I learned:
I have to say that I really did learn a large amount of information from this book. I really feel like I got a good understanding of how to apply messaging patterns to various sorts of problems.
I feel like this book gave me a really big toolbox of all the possible tools that I would need to solve any messaging pattern.
I also learned just how easy it is to use MSMQ and JMS and throw messages on a pipe. It’s really not that bad.
After having used BizTalk a while ago and not really understanding what it was or what it was trying to do besides allow you to change file formats between a bunch of different clients, I feel like this book definitely opened up my eyes to the true value of a solution like that. If I had a BizTalk project now, I am sure I would be much more effective after reading this book.
Overall, I would definitely recommend that every developer that is working with messaging read this book. Even if you are not, I would still recommend reading it so that you can have your eyes opened up to how messaging can solve many of the problems we try to solve in create-ftp-batch-cron-jobish ways.
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.
I recently completed reading Pro Android 2. It is a pretty large book, so it took me awhile, but I finally got through it. I hadn’t really read any other Android books, so I don’t know how it compares.
The book goes through creating an Android application using Eclipse. It contains many source code examples that are very complete. The book really seems to be focused more on getting going vs going in-depth with the APIs.
- Great jump start diving right into Android development without wasting much time.
- Very complete examples that can get you going and can be modified for your own application.
- Balances basic examples with more complex architectural constructs well. There is a good mix of examples that build on basic concepts and show how to implement more of an MVP style of development.
- Covers a pretty wide breadth of the Android platform, which makes it easy to know what exactly is capable.
- Although the beginning of the book was very interesting and informative, some of the chapters seemed to drag on.
- A whole huge chapter devoted to search. Search is not something that most applications would need to make use of.
- A whole huge chapter on 3d application development. Not something I felt should have been in the book. Pretty boring and actually really scary. I don’t think I’ll ever develop a 3d application for Android.
What I learned:
I had already started building my Android application before reading this book, so not very much of it was completely new to me, but I definitely learned some things from the book.
I was really surprised to see how easy 2D animation is with Android. The book does a good job of explaining it and providing examples. I feel like I could very easily implement 2D animation after reading this book.
I learned about how to create and use content providers. This aspect of Android development is a bit tricky, but I felt like Pro Android 2 did a good job of explaining it and providing examples that I would be able to use.
I also learned to create a home screen widget. The examples in the book were really good and provided a complete usable implementation that could be easily used as a base for creating your own.
Towards the end of the book, Titanium Mobile is mentioned. Titanium Mobile is a WebKit-based native application development framework which allows developers to write applications that target multiple platforms. It looks really cool, and I kind of wish that was the first chapter in the book so that I could have explored that before getting so far into actual Android development.
Overall, I would definitely recommend the book. I feel pretty confident that someone with no Android experience should be able to pick up that book and get going with their first application. I definitely learned some things the hard way before I read the book.
I wish I could take a time machine back to the year 2000 and read it then.
So much of the information in the book seems to be concepts that many software developers understand and take for granted as general knowledge now, that wasn’t at the time of its writing.
The book is very much a collection of knowledge from years of practical experience writing code. It is very specific in stating what kind of specific coding practices should be carried out and which ones should be avoided.
The content of the book lays somewhere between the low level software construction in a book like Code Complete and a book targeting a higher level methodology or project management.
- Years of experience packed into a small package.
- Most of the advice in this book is timeless.
- Practical real world truth instead of theoretical talk.
- Excellent focus on automation for everything you can automate.
- Technology independent advice.
- There were definitely some dated pieces of advice that I wouldn’t recommend following today.
- If you are already familiar with many of the software craftsmanship or general agile principles, much of this book will echo what you already know. (Can’t fault the authors for that since this book is probably the origin of much of that information getting out, yet if you haven’t read the book, you should know what to expect.)
What I learned:
I really liked the section of the book that talked about using “tracer bullets” in software development. Basically the idea is that you can either prototype the software or build what you know and then adjust your aim to reach the user’s real requirements instead of trying to specify up front.
I think many times in development we get hung up on knowing all the details, but sometimes we need to fire “tracer bullets” first to see if we are hitting the target.
I also realized that I am guilty often of programming by coincidence. Sometimes I will have put a magic incantation into the code and not really understood why it worked. It is very important to understand why something works, not just make it work.
This book is a self-published book, which is really a collection of essays. Be prepared for that before you read the book, so that you know what to expect.
It is not a book that tells you how to exactly do Kanban or Scrumban, but it gives you ideas about Kanban and lean concepts and how to solve certain problems you might face in implementing a Kanban process.
Some parts of the book might be a bit difficult to understand without a background in lean methodology, but overall most of the common problems and solutions are understandable. This is definitely a book you could study and contemplate on as you read through the material and look at the charts.
- Excellent use of diagrams and pictures of real Kanban boards to illustrate points.
- Lots of different solutions for common Kanban problems.
- In depth talk about strategy and reason behind different possible solutions.
- Several unique perspectives on many of the concepts presented.
- Not exactly an easy read. It is a little rough and some of the concepts rely on knowledge outside of the context of the book.
- Some of the assumptions are a little broad and aren’t backed up by much real data.
What I learned:
This book really expanded my mind about different ways of implementing Kanban, and solutions for some of the common problems. Some of the solutions surprised me, but made sense.
I learned more about the reasoning behind limiting the WIP to force the system to self-correct. I had not considered that strictly limiting the WIP would force freed up resources to automatically move to help resolve the clog in the pipe since they will not be able to take in new work.
Corey presented a great technique on planning by having a just-in-time planning session when the number of items in development reaches a certain threshold. I had heard of this technique before but had not seen a practical implementation of it.
I would definitely recommend this book to expand your thinking on Kanban software development. If you are looking for instructions on exactly how to set up your Kanban process, this book probably won’t help you, but if you are looking to understand more about the why of Kanban and how to solve particular problem or pain points, get this book.
It has been awhile since I wrote a book review.
There is one coming soon, but I wanted to talk about why it has been so long.
Simple answer… I stopped reading.
What happened? Well, I got caught up with switching jobs twice. Lots of different things going on. I started a running program, etc… etc… excuse… excuse.
I wasn’t following my own advice.
It is really important to take a moment every once in awhile, when you feel like you are off track or not reaching your goals, to reassess your priorities and goals and figure out what you need to get back on track.
You have to set a schedule
That is primarily where I failed and that is how I am succeeding now again. At one point I was reading through books about 2 a month, but pretty soon a few months passed by without one book read.
When I was successful at reading it was because I had set up a schedule of reading every day for so much time.
The simple matter of it is, as humans we are not good at making good choices about priorities without explicitly planning them out.
Now that I have set up a schedule of reading a minimum of 30 minutes each day, I am making progress again, and much faster than I thought.
Aren’t you being a little strict?
You may think that just reading blogs is enough to keep up with the information stream, and it may be, but it probably isn’t going to really expand your mind like a book will.
Why I recommend reading technical books (although, I would argue a book on people skills and other self-improvement books should also be mixed in):
Breadth of knowledge will increase.
You will learn more about things and understand more of what is available to you even if you do not employ all the practices and technologies in the books you read.
Depth of knowledge.
Sometimes drilling down into an API or deep into a technique can help you truly master a technology or practice way more than hacking out code or consulting APIs to just find what you need to know.
This one is a surprise to most people, but what you read is what you are excited about, not the other way around.
Try it if you don’t believe me. Pick any topic and start reading about it. You will become passionate about that topic.
If you want to be a better software developer, read about software development.
Reputable source of authority when influencing decisions.
You can have the best idea in the world but if your only authority is yourself, it doesn’t hold much credibility. It is much more effective to say, “I think we should do it this way. In Code Complete, Steve McConnell says…”
Unconscious knowledge absorption.
I have always been amazed by how much information I picked up from reading than what I was conscious of knowing.
Sometimes when I write code, I intrinsically know it is the right way to do it, because of an unconscious conditioning. (Make sure you read good books or you will have the negative aspect of this effect.)
My little tip
One great way to get your reading done, and to stay in shape at the same time, is to do it on a treadmill.
I have been doing this for awhile now and it really makes me feel like I am using my time wisely.
You can just walk on the treadmill, set a little incline to burn some extra calories, and after awhile you’ll forget you are walking.
Took me awhile, but I finally finished reading: The Definitive Antlr Reference: Building Domain-Specific Languages (Pragmatic Programmers)
It is hard to separate reviewing ANTLR from reviewing this book, which is written by the author of ANTLR, Terence Parr. ANTLR is a fantastic tool, which really opened my eyes to the capabilities of creating DSLs to solve what otherwise would be very difficult problems. I looked up many resources on ANTLR, and by far this book is the best resource available. If you are going to try to learn to use ANTLR buy this book.
- First few chapters start out very simple and easy to understand.
- Very good examples of how to use ANTLR with real code and real programming languages.
- Excellent coverage of each feature of the tool, and why it was built that way.
- Builds on concepts of language parsing while introducing ANTLR features.
- Gets a bit complicated near the end of the book. Some of the examples and concepts get pretty deep into complex language parsing, although there is a warning about it.
- Missing information on best practices for using ANTLR. (Would have liked to see a chapter dedicated to that subject.)
What I learned:
I had no idea that creating a DSL could be so easy. Language parsing really is not that hard. It is intimidating to think about creating a DSL, but with the right tools, it is not really very difficult at all.
I learned how to use ANTLR and got most of my questions answered about how to accomplish pretty much anything I would need to do in ANTLR.
There was a topic about using string templates that made me realize how useful it is to not hard code the code generation into the tree parsing when creating a language. By separating out the code generation into templates, it is possible to target several different languages easily.
I got a much better understanding about general language parsing and design, as well as a good understanding of Abstract Syntax Trees (ASTs), why you would use them, and how to use them effectively. I got a good understanding of why you would need a multi-pass parser for parsing a language.
This book will change the way I look at many problems. I feel pretty confident in implementing DSLs to solve the right kind of problems after reading this book.
I have implemented hand written language parsers in the past, but after reading this book, will never do that again and would highly recommend reading this book and checking out DSLs in general. It is easier than you think.
I finally finished “Implementation Patterns” by Kent Beck and I have to be honest. I am a little disappointed. Let me preface this by saying my review of this book is not a reflection of my view of Kent Beck. Kent Beck is a programming hero. He pioneered the adoption of Test Driven Development, invented Extreme Programming and was one of the creators of JUnit. With that said, I will be honest about the book.
This book is about the low level construction of software and algorithms. Implementation Patterns looks at the patterns which are applied to programming when creating even the simplest of designs.
The book covers patterns relating to classes, state, behavior, methods and collections.
- Excellent introduction on implementation patterns
- Good reference for knowing how to call the thing you know is right, but can’t explain.
- Section on collections is very good for understanding trade-offs between collection types.
- Doesn’t read much like a book. It is a bunch of little pieces on each topic, but they don’t really tie together smoothly.
- Some of the patterns I disagree with, especially the ones involving using inheritance over a different solution. (I am not a fan of concrete inheritance.)
- The book feels like it was not fun to write, like it was a labor of filling up pages.
- The treatment of collections perhaps belongs in a different book. The appendix which talks about performance measurement definitely does. A large amount of the book are these two topics.
- The framework section seemed a little strange in this book and it didn’t really have enough information to be useful.
What I learned:
There is always something still to learn, and I did learn one very important concept from this book. Kent talks about Values and Principles in the 3rd chapter of the book. This concept has been something that I haven’t been able to put into words, but I have known it is there. Kent very clearly describes the differences between values of programming and principles, and how principles are built on top of values. Often, I have a hard time in my mind accepting the need for making trade-offs between one or more principles. He very clearly addresses this issue, leading back to the values for ultimately making the decision.
I learned many names for things I was doing, but without knowing what to call them.
I also learned quite a bit about Java collections which I did not know before. I found out some good considerations when writing code to determine performance, which I would probably have not considered until reading this book.
This book is very much in the spirit of “Code Complete” in that it talks about software construction at a pretty low level. The book is written from a Java perspective, but easily most of the ideas transcend a particular language. It is very rare to come across books which have the potential to completely change the way a person thinks about writing code. This is one of those books.
One of the best things about this book is the hands on approach to making the code clean. It is one thing to talk about how to make code better, but it is another thing to use real world code and show how it is transformed.
- Great explanation of why clean code is important.
- Very detailed information on choosing good names.
- Excellent advice on function size and parameters.
- Very convincing chapter on why comments are usually bad vs writing code that expresses its intent.
- Unit testing advice, how to keep tests clean.
- Excellent coverage of concurrency problems and solutions.
- Real examples of refactoring and making code clean from real projects.
- Nice section on code smells and heuristics.
Honestly, not much here at all… the only thing is a chapter on formatting which I found not that important, since most of us use auto-formatting rules in our IDEs.
What I learned
It’s hard to pick out all the little pieces of “ah ha” moments when reading this book, but here are a few in particular that stuck out to me. I may have known some of these things, but reading them in print made them so much more clear and concrete.
Methods should try to not have parameters. The less parameters the better. I kind of already knew this, but in this book it is made really clear why having 1 parameter is so much better than having 2.
Try not to overload methods taking different parameters. When looking at some of the code examples here, I could very clearly see why having another method was better than an overload.
I was relying on getter and setter methods in my code too much. I learned that I should be thinking of a way to not have to use getter and setter methods by making the class do the work or moving parameters inside the class.
I was thinking the more Java Doc or NDoc the better, but after reading the section on comments, I realized that having that hard and fast rule is not really good. Now I am only going to use Java Doc or NDoc where it actually provides information, not just as a rule.
Don’t return null. This seems obvious, but I realized that instead of having to try and deal with null parameters, a much better strategy is to just never return null in your code so that you never have to try and deal with null.
Several bits about concurrency. It was really interesting to see why concurrency issues can occur from a byte code viewpoint. I learned about a few places I didn’t realize that concurrency issues could occur and some good techniques for putting concurrency problems into a single class and not letting them leak into the entire application.
If you know someone at your workplace who you consider to be a great developer, ask him what technical book he is reading. He will have one to name almost always.
The simple fact of the matter is that great developers read books
Most highly skilled developers will have a library of books. Not every person who has a stack of books on their desk is a great developer though. One thing to look for is to see if the book bindings look like the books have ever been opened. Some developers just collect books and don’t actually read them. When I am interviewing someone for a development job, I will often ask about mocking and books read recently or favorite books. Chances are if someone knows about mocking and is reading good development books they are a good developer. Seems a little wild to make a large statement like that, but experience has taught me this is true.
Why do great developers read so many books?
There are actually quite a few answers to this question.
A great developer always knows that there is always something more to learn.
It doesn’t matter how smart we are, or how much we think we know. There is always something to learn. Someone can always teach us something we didn’t know and we can always improve. As soon as someone stops learning they stop growing, and if you’re not growing in the software industry, you are shrinking. Someone who is learning is someone who is always getting better. A person like that is also very likely to analyze problems in a way that asks questions and looks for better solutions rather than jumping to conclusions. In a field this big that is growing so rapidly it is impossible to know it all. I often fantasize about being a developer in the 80’s when you could perhaps know it all, but nowadays the amount of technology, libraries, frameworks, best practices, methodologies, tools, etc are growing so rapidly that you can’t even hope to keep up at a steady pace. You just have to keep from drowning.
A great developer always knows that there is someone to learn from.
What’s the difference between getting in an argument, excuse me, discussion, with a great developer and a mediocre developer? Authority. A great developer can speak with authority, because it is not his idea or words that he is saying, but that of someone smarter than him. That of a whole bunch of people smarter than him. If you are arguing with a well read developer you are most likely arguing with Robert Martin, Don Knuth, Steve McConnell, and others. A developer who knows that someone has something to teach them not only values other people and ideas, but values teaching. A great developer recognizes that it has all been done before. That someone else has asked the same question, spent many hours researching it, and has a better solution than they could make up in 30 minutes. A good developer says “how can I solve this problem?” A great developer says “how did someone else solve this problem?”
A great developer wants to do things the right way.
You’ve heard it called elegant code, software craftsmanship, clean code or many other things, but I think deep down it’s all about doing it the right way. A great developer looks for other people’s views on how something should be done, ever in search of the elusive “right way.” How to design the database; how to write good unit tests; how to separate concerns; how to build good software. Books contain some of these answers and a great developer turns to others for help. A great developer knows from experience that the first way we think to do something is not likely to be the best way, so he is interested in seeing what someone else has to say on the subject.