Earlier this week I finished reading Uncle Bob’s latest book The Clean Coder. Robert C. Martin is a great writer and I very much enjoyed reading his previous books. His latest work is no exception and I found it to be yet again a fascinating read.

This book is all about professionalism. This is something that is very much needed in the field of software development. It describes how a professional software craftsman behaves, how he deals with tight schedules, irrational decisions made by managers (for those rare occasions that this happens), conflicts and so forth.

The preface of the book takes you right by the throat, talking about the Challenger disaster. This has been applied to the field of software engineering many times already (check out this blog post from Gustavo Duarte which is one of my all-time favorites), but still, it definitely never wears off.

The book is filled with stories and anecdotes from the rich career of the author and the lessons he learned during these 40+ years in the IT industry. Some of the ideas in there are definitely challenging (like staying out of the zone and building up focus instead), but nonetheless they put a very  interesting perspective on things.

Don’t let yourself get carried away by some of the hard statements but try to focus on the underlying ideas and try to think back on some of the good and bad situations that you ran into during your own career. Trying to reflect on those moments and considering how we could act more professionally lies at the heart of improving ourselves. I definitely learned a lot while reading this book and I encourage you to pick up a copy as soon as possible and take some time to read it.

Two thumbs up!

1. CoffeeScript – Accelerated JavaScript Development

CoffeeScript – Accelerated JavaScript Development, written by Trevor Burnham, gets you up and running with CoffeeScript in no time. This book was recently released by the excellent Pragmatic Programmers which only increased my expectations.  And I must admit that Trevor did a tremendous job explaining the ins and outs of this fairly new programming language. With only a good 120 pages, it’s a very quick read so one is able to start coding away as soon as possible.

The book contains six chapters. The first four chapters basically cover the different language features of CoffeeScript. The last two chapters explain how to use CoffeeScript both on the client-side along with jQuery and the server-side with Node.js. At the end of each chapter there’s an example application (5×5 solitaire) that gets refactored throughout the book as more language features are covered. Every chapter also provides some exercises where you can put your teeth into.

Now, I have to warn you that in order to get the most out of this book, you need to have some decent knowledge of JavaScript. Some of this stuff isn’t trivial and being able to imagine how the underlying JavaScript would look like is almost required.

I highly recommend this book if you want to learn this great little programming language.

2. JavaScript Web Applications

By the time of this writing, JavaScript Web Applications by Alex MacCaw hasn’t officially been released yet. It’s still in the early release phase which means that there are still a good number of typos in there. That aside, this book contains some rock solid content on how to build client-side JavaScript applications.

This book isn’t about server-side applications with the occasional piece of JavaScript code used in only a couple of web pages. As it’s name implies, this book is all about building MVC applications for the browser using JavaScript.

After the obligatory introductory chapter, chapter 2 up to chapter 6 discuss each part of the MVC pattern and events. The author thoroughly explains each part of this design pattern while implementing his own client-side MVC library. Lots and lots of code here.

Chapter 7 provides a clear explanation on dependency management in JavaScript and how to use module loaders to mitigate this problem. Chapter 8 and 9 cover some of the API’s that come with the upcoming HTML 5 standard, particularly on how to deal with files using JavaScript as well as WebSockets. Chapter 10 deals with testing and debugging. But chapter 11 is definitely my favorite chapter of the book where the author shows a good number of techniques on deploying a JavaScript web application and how to deal with performance. This chapter alone was a real eye opener. Finally, the last three chapters provide an in-depth introduction to three of the most popular open-source client-side JavaScript libraries out there, namely Spine.js, Backbone.js and JavaScriptMVC.

Again I have to warn you that this book is definitely not for JavaScript beginners or the faint of heart. There were times that it even got me scratching my head from time to time. There’s some really neat JavaScript stuff in there, so I highly recommend that you pick up this book some time on your JavaScript learning path.

Happy reading an until next time.

Last week, I finished reading Hands-on Node.js written by Pedro Teixeira. I very much enjoyed reading this concise introduction to Node.js, and although it’s targeted towards beginners, I certainly managed to pick up a few nuggets myself here and there.

After the obligatory introduction, the first chapter opens up with an explanation of why Node.js runs on an event loop and why JavaScript eventually got chosen as the preferred language.

The next chapter shows how to install Node.js on different platforms and also how to get npm up and running.

Chapter 3 discusses the event loop and modules. These first three chapters make up the first part of the book, which provide you with a more theoretical understanding of what Node.js is all about.

The next part of the book contains the chapters that go over the different aspects of the 25 built-in modules that come with Node.js. As the title implies, these chapters contain a lot of code examples and also provide the reader with a good amount of exercises (and also solutions). There are even a chapters that discuss how to debug and unit test Node.js applications.

So, if you want to start out learning about Node.js then this book is your first stop. You can buy the ebook directly from the author for only $ 4.99! Pedro certainly knows his stuff when it comes to Node.js, so this is a real bargain. Also make sure to check out his excellent screencast series on this very topic which are free to watch and download.

Happy learning!

1. The 48 Laws of Power

The 48 Laws of Power, written by Robert Greene, totally blew me away. I can’t remember where I picked it up or who brought this book to my attention, but kudos anyway. The basic premise of this book is that some strategies keep you in control, while other acts of human nature decrease your influence. This book isn’t necessarily about you gaining power over others, as it is more about actions that prevent others from manipulating or gaining control over you or your close environment. Every law is illustrated with real-life stories about historic figures and how their actions put them in a powerful position or how their mistakes drove them to a cliff.

I wish I had read this book many years ago, but better late than never, right? I’m definitely going to reread several portions of this book in the near future in order to get a better grasp of some these laws. I have to admit that sometimes, this book is a bit much when you read it for the first time.

2. Dinosaur Brains – Dealing with All Those Impossible People at Work

I had this book literally collecting dust on my bookshelf for several years now, so finally being able to read this book has been well overdue. Dinosaur Brains, written by Albert J. Bernstein and Sydney Craft Rozen, is all about how we sometimes react and behave purely by our primal instincts, when the cortex in our brain loses control and falls back on lizard logic in some situations. Funny enough, this book has taught me more about myself than about my current co-workers or former colleagues. This metaphor of a prehistoric creature illustrates how our brain triggers a fight, flight or freight response that is sometimes well beyond our control. But this isn’t a lost cause either. This book not only provides the rules of the dinosaur brain, but it also contains a lot of advice on how to use this knowledge to your own advantage. So, overall a very interesting read.

3. Drive – The Surprising Truth About What Motivates Us

I picked up Drive – The Surprising Truth About What Motivates Us after I watched this inspiring talk by Daniel Pink, which I briefly mentioned in this blog post. The author makes a very strong case for what he calls Motivation 3.0, which is based on three concepts:

1. Autonomy – based on the principles of self-direction, this lets knowledge workers decide how, when and where to do their job.
2. Mastery – getting people in a state of “flow” by letting them work on stuff that they’re passionate about. “Flow” is a state of mind that where time seems to be passing by without noticing. The author clearly explains why a restrictive working environment prevents people from getting into their “flow”. 
3. Purpose – the believe that there’s more to work than just making money. The fact that there’s meaning in what you do day in and day out, enables our intrinsic motivation.

I also couldn’t help but notice that this book tends to lay out the basics of systems thinking, which is a topic that I definitely want to learn more about.

Do yourself a favor, pick up and read this book or at the very least, watch this excellent talk. Buy this book as a gift for your boss and tell him that all the cool managers are reading this book .

4. Pragmatic Thinking and Learning – Refactor You Wetware

Pragmatic Thinking and Learning, written by Andy Hunt, is also a book that I wanted to read for quite some time now. As he is one of the co-authors of The Pragmatic Programmer, I had some very high expectations. And I must say that those expectations were only partially fulfilled. The first few chapters were a reiteration of Daniel Pink’s book A Whole New Mind, but then applied to the world of software development. There was even some content in there from the book Dinosaurs Brains, which I had just finished reading at the time. But if you haven’t read these two books before, then these first chapters will definitely be an eye opener.

Nonetheless, I did manage to pick up a few neat ideas about learning in general and how to apply those to my own learning activities. But I couldn’t get rid of the feeling that most of the content was just an iteration of what I already picked up from other books and articles.

Don’t get me wrong here. This is truly a great manuscript with a lot of gems in there. If you’re not already familiar with this stuff, then this book will definitely rock your boat and I would highly recommend it.

So, happy reading and until next time.

I really learned a lot from reading the first edition of C# in Depth, so I was very glad that I finally found some time to make my way through the second edition. The content on C# 2.0 and 3.0 was only slightly revised compared to the first edition. Never change a winning combination .

But the final part of the book was the one that most interested me. This part discusses the features provided by the C# 4.0 compiler like optional parameters, named parameters, covariance/contravariance and last but not least, the dynamic keyword that got it’s very own chapter. The last chapter for this final part of the book is completely devoted to Code Contracts, which is not a language feature. I personally don’t like the way that Code Contracts are currently implemented by the .NET framework. I do hope that these concepts are going to be part of the C# language one day, which will be a major improvement regarding enforcing such contracts. Until that day, I think I’m going to stick with my own implementation.  

Anyway, I still think that the title of this book is spot on. If you want to bring your C# skills to the next level, then this book will be you guide. This book is filled with knowledge that only a true C# language expert can deliver. Definitely worth the time and effort.

Happy reading.

I already finished “Driving Technical Change” a few weeks ago, but I  got so caught up with other stuff that I almost forgot to actually sit down and write a review for it. I was very much looking forward to reading this book, and I must say that it certainly didn’t disappointed me. The author, Terrence Ryan, did a very good job distilling and capturing a good number of patterns and techniques for trying to convince people to adopt the concepts, tools and technologies that you yourself are trying to put forward. It’s not entirely gospel, but there is a lot of wisdom and definitely a number of great nuggets in there that might come in handy throughout ones career as a passionate software developer.

There are three main parts in the book. The first part elaborates on seven skeptic patterns. These skeptic patterns describe a particular stereotype of humans that you might encounter in your organization or work environment that are opposed to your ideas in one way or another.

These skeptic stereotypes are:

• The Uninformed
• The Herd
• The Cynic
• The Burned
• The Time Crunched
• The Boss
• The Irrational

The second part of the book provides a number of countering patterns and techniques that can be used to ‘massage’ these skeptic stereotypes so that they come more in line with your way of thinking. Some of these techniques are claimed to be universal while others only work on certain types of skeptics.

This part fills your toolbox with the following patterns:

• Gain Expertise
• Deliver Your Message
• Demonstrate Your Technique
• Propose Compromise
• Create Trust
• Get Publicity
• Focus on Synergy
• Build a Bridge
• Create Something Compelling

The third and final part of this book then talks about some strategies on how to effectively apply these countering techniques and patterns. With the information laid out here you’ll able to sort out a good approach for taking action.

These strategies are:

• Ignore the Irrational
• Target the Willing
• Harness the Converted
• Convince Management

With only a good 125 pages, this book is a concise collection of patterns and practices that are targeted towards influencing the people in your organization or working environment. This book is a highly recommended read when you want to push things forward at your work place.

Last week I finished reading the first edition of Extreme Programming Explained, written by Kent Beck. I explicitly wanted to read the first edition, that I purchased via AbeBooks, which is also the first book that appeared in the series of books on XP. I’ve read a couple of book reviews of the second edition on the interweb where some have stated that the second version is somehow less ‘extreme’ compared to the first edition. That’s why I went for the first edition as I wanted to learn from the ‘original’. 

While it seems that Scrum and Lean are getting all the buzz in agile software development these days, why on earth would I want to pick up a book on Extreme Programming that has been written back in 1999? Well, it’s my current feeling that XP is the ‘core’ agile methodology. While there was some buzz around this software methodology in the late 1990s and early 2000s, it has never been commercialized nor pursued by hypesters, at least not on the same scale as Scrum and Lean. I’m not saying that Scrum and Lean are therefore bad and should be avoided. On the contrary! I’ve been part of a Scrum team for many years now where we’ve been complementing this project methodology with XP engineering practices like unit testing, continuous refactoring, continuous integration, etc. … . This has been working because of these XP practices, not the other way around. But what I’m seeing more and more lately are teams that are adopting Scrum without any of these solid engineering practices, especially in enterprise environments. Therefore I think it’s important to learn more about XP, which is one of the agile methodologies that somehow managed to preserve its values throughout these years without losing its balance. I’m with Uncle Bob when he states the following in his blog post on Bringing Balance to the Force: 

“I, for one, consider the agile movement to have been inundated by a vocal and enthusiastic cohort of project managers, waving their scrum-master certificates, or their Lean and Kanban books.  They have overwhelmed the original movement and changed it into something new.   Agile is no longer about a balance between the technical and non-technical parts of development.  Rather it has become a discussion almost entirely dedicated to non-technical issues.  Agile is no longer about healing the divide, or closing the crevasse.  The agile movement now represents one side of the crevasse.”

Anyway, back to the book review. I personally found this book to be a very fascinating read. It’s divided into three major parts:

• The Problem – This first section sets the stage for XP. The chapters in this section discuss the value proposition for XP while also showing the disciplines behind it. The four values of XP are Communication, Simplicity, Feedback and Courage while the fundamental principles are Rapid feedback, Assume simplicity, Incremental change, Embracing change and Quality work and the four basic activities are Coding, Testing, Listening and Designing. These values, principles and activities are broadly discussed throughout this section. Basically, here you’ll get a high-level view of Extreme Programming.
• The Solution – Given the values, disciplines and activities from the first part, the second section elaborates on the strategies and practices that make up XP. The practices discussed are The Planning Game, Small releases, Metaphor, Simple design, Testing, Refactoring, Pair programming, Collective ownership, Continuous integration, 40-hour week, On-site customer and Coding standards. The book doesn’t provide an explanation on how to do these practices. It’s more about why these practices are important and why they’re under the XP umbrella.
• Implementing XP – The third and final section of the book deals with a number of various topics like how to adopt XP, when to use it, when not to use it and what it takes from people that are part of an XP team. I personally got the most value from the chapters in this section.  

Something that the author kept repeating throughout the book was the importance of how the office furniture is arranged for an XP project team. I never really thought about this, but after reading this book I’ve come to realize how important this can be. Being able to easily pair program and get the customer to sit with you can in fact be a game changer.

Here are some of my favorite quotes that I picked up while reading the book:

“No single action takes the life out of a team or a person more than being told what to do, especially if the job is clearly impossible. Primate dominance displays work only so long in getting people to act like they are going along. Along the way, a person told what to do will find a thousand ways of expressing their frustration, most of them to the detriment of the team and many of them to the detriment of the person.”

“So you code because if you don’t code , you haven’t done anything. You test because if you don’t test, you don’t know when you are done coding. You listen because if you don’t listen you don’t know what to code or what to test. And you design so you can keep coding and testing and listening indefinitely.”

“Code gives you a chance to communicate clearly and concisely. If you have an idea and explain it to me, I can easily misunderstand. If we code it together, though, I can see in the logic you write the precise shape of your ideas. Again, I see the shape of your ideas not as you see them in your head, but as they find expression to the outside world.”

“The difference is between playing to win and playing not to lose. Most software development I see is played not to lose. Lots of paper gets written. Lots of meetings are held. Everyone is trying to develop "by the book", not because it makes any particular sense, but because they want to be able to say at the end that it wasn’t their fault, they were following the process. Software development played to win does everything that helps the team to win and doesn’t do anything that doesn’t help to win.”

I highly recommend that you pick up and read this book. It’s only 166 pages and a bargain on AbeBooks or Amazon. By reading this book I learned a lot about agile software development and more importantly, how to strike a balance in customer collaboration and technical stuff. The book contains a tremendous amount of knowledge and wisdom. I sometimes had a very hard time putting it away as its also very nicely written. Two thumbs up!

Earlier this week I finished reading JavaScript Patterns, written by Stoyan Stefanov. After I very much enjoyed reading his previous book titled Object-Oriented JavaScript last summer, I instantly bought JavaScript Patterns when it came out and put it on my priority reading list. While Object-Oriented JavaScript is more an introduction to the JavaScript language and targeted towards folks that are either new to the language or already been using it superficially for some time, JavaScript Patterns  wonderfully succeeds at building on existing knowledge and taking it to the next level.

This book might as well have been titled “The JavaScript Way”. It’s only 200 pages, but literally packed with great concepts and knowledge about JavaScript and is very dense. While reading this book you can easily notice that the author has an immense amount of experience with JavaScript combined with great writing skills.       

The book not only taught me about JavaScript programming. It also challenged the way how I code in other programming languages as well. It made me think about the differences between static and dynamic languages as well as programming languages that have lots of features compared to others that have a more compact feature set but seem to thrive because of their conciseness.

The book has eight chapters. After a short introductory chapter, the author dives right in by laying out a wide amount of JavaScript essentials in the second chapter.

The third chapter discusses Object/Array literals and constructors while the fourth chapter provides in-depth information about functions in JavaScript.

Chapter five and six are real masterpieces. The fifth chapter is dedicated to object creation patterns, explaining private properties and methods, the module and sandbox patterns and much more. Chapter six discusses several ‘classical’ patterns (as in class), ways to accomplish inheritance in JavaScript, mixins, etc. This chapter is also a nice follow-up on chapter six in Object-Oriented JavaScript. These two chapters were real eye openers for me.

Chapter seven provides JavaScript implementations for the Gang of Four patterns, like the singleton, factory, decorator, strategy, mediator, observer amongst others.

Chapter eight is all about programming JavaScript in the browser and manipulating the DOM. I personally found this to be very interesting and good to know, but not that useful. You don’t have to deal with these things anymore as libraries like jQuery are taking care of that stuff for you. Off course, this doesn’t change my view and perception of the entire book. The parts on deploying JavaScript files and the discussion on loading strategies definitely make up for it.      

Summarized, this book is AWESOME and is now part of my list of favorite books. I can only encourage you to pick up this book. It’s definitely not a book for beginners, but if you want to take your existing JavaScript skills to the next level and beyond, then reading this book is highly recommended.

Just before I recently decided to turn a new page in my professional career, I came across this book called The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting. Before I made up my mind about being a consultant, I purchased this book and read a few parts of it (specifically chapter five “What You Need To Ask Before You Join a Technology Consulting Firm” and chapter ten “Is Consulting Right for You?”). I recently read the book from cover to cover in order to find out more about what it means to work for a consulting company. So far, I’ve only been working as an in-house developer for companies that aren’t in the software business itself. This basically means that I’ve been working to support and find solutions for the core business of the company, where software is just a means to an end. Companies tend to value the people that bring in the most revenue.  In a lot of cases, an in-house developer is usually seen as a cost instead of someone who brings in revenue.

As a consultant working for a technology company, software is the core business which is a slightly different ball game compared to being an in-house developer. I use the word ‘slightly’ here because as a consultant, there’s a high chance you’ll probably end up developing software to support businesses of other companies that aren’t also in the technology business. But still, I think that working for a company that makes money in your own field of expertise is a good place to be.

Anyway, this book is targeted towards helping consultants (or future consultants like myself) to understand the economics of the technology industry. It’s filled with great advice for all folks that are new in the IT industry, coming from college or otherwise. But for more seasoned developers, there are some great nuggets in there as well. Although the book is mainly focused towards consultants, lots of the advice in the book is also applicable to in-house developers.

Take a look at the twelve chapters to get a quick glimpse of the content. The wisdom collected here is drawn from the author’s own experience as well as from others that contributed content to the book like Jason Bock, Michael Hugos, Derik Whittacker, Chris G. Williams, … etc. The content of the book is interspersed with annotations and anecdotes of the contributors which makes it highly interesting and fun to read. The last chapter is an enumeration of essays from the contributors. These essays all promote doing community work in one way or another like working on open-source projects, writing books, organizing user group meetings, etc for gaining more visibility as a consultant. While I’m certainly highly in favor of doing these things, doing them just for your own advancement or sales purposes is definitely the wrong reason. In my opinion, the author could have done a better job to warn the reader that contributing to a community only for visibility reasons isn’t the right perspective for doing these kind of things as it tends to do more harm than good and probably won’t last either. Again, putting out advice to do community work in order to gain visibility is one thing, warning about the dark side of the coin couldn’t hurt either.

So if you are working as a consultant or thinking about becoming one, just pick up this book and give it read. It’s also available in audio format if you fancy that. I learned a couple of things from this book and probably so will you.

After having listened to the recording of a speech by Daniel Pink, I quickly decided to purchase the audio version of A Whole New Mind: Why Right-Brainers Will Rule the Future. In this book, the author first starts to describe how our brains work from a high-level point of view. The human brain is divided into two hemispheres, a left and a right part. The author explains the differences between these two parts of our brains, stating that left-brain (L-directed) thinking implies more logical, linear reasoning while right-brain (R-directed) thinking is more holistic and artistic.

The message that he is trying to bring across, is that while society highly values L-directed thinking, R-directed thinking is getting more and more important in the world of tomorrow. There are three basic questions that identify and point to R-directed activities:

1. Can someone overseas do it cheaper?
2. Can a computer do it faster?
3. Am I offering something that satisfies the nonmaterial, transcendent desires of an abundant age?

The answer to these questions should be “no, no and yes”. If not, then those kind of activities can be automated or done much cheaper by out-sourcing. Those kind of activities are delineated as left-brain activities.

The second part of the book is called “The Six Senses”, which are:

• Design
• Story
• Symphony
• Empathy
• Play
• Meaning

For each of these senses, the author tries to find real-world examples and stories to prove the values of these aptitudes.

In short, this is simply a fascinating book. I can highly recommend this book to just about anyone. Two thumbs up!