The Code Dump

He would probably object to me calling him that, but I’ve long ago realized Kent Beck is one of the precious few who deserve the title “a mastermind”. With Extreme Programming, Test Driven Development, Responsive Design, the Four Elements of Simple Design and more under his belt, who can claim otherwise?

After attending a workshop of his about a year ago and listening to him talk a whole day I was astonished. I tried to pick his brains to understand what makes him tick. Of course there are many factors here – reading over 10,000 books and being smarter than most would help anyone. But something a bit less common takes a major part in this in my opinion, what Kent told me he has: a “habit of desperately wanting things to make sense” and his ability to take things apart until they do.

I recently picked up another of Kent’s books, Implementation Patterns. I love this book because it shows exactly that: his process of thinking and breaking things apart in order to understand them. The book provides a rare glimpse to his method of decomposition. Since I’ve been coding for years, a lot of the patterns made sense to me or seemed trivial. But the “magic” is the fact he was able to put into words things that for me were just hunches. Actually explaining what makes you sense a method is too long or what is a proper name for a variable is something I’ve never seen done with such care to specifics.

Because it’s such a quick read, I think anyone will benefit by reading Implementation Patterns. More than helping you understand our craft better, it will provide a new outlook on decomposing and judging your designs and pretty much everything else.

You should subscribe to my feed and follow me on twitter!

Starting with a test means that we have to describe what we want to achieve before we consider how.

This is another post in my book reviews series. I finished reading Clean Code a few days ago and loved it. It makes me feel good, seeing my decision to wear the Clean Code wristband a few months ago was a smart one.

After I finished it, I felt a bit weird writing a blog post about it, because, just like the previous books I’ve blogged about, I found this book simply awesome. Then I thought about the fact it’s simply because I’m reading those books that show up enough in other contexts that I upped them in my reading queue enough to get on top.

The book is about practical, low level details of writing good code. There are chapters about comments, naming, functions, you name it. In a way, it reminds me of Code Complete, other than the fact you can see it’s oriented for more practiced developers.

Like in his Agile Software Development book, Uncle Bob made sure to fill this one with code. Actually, this book has a lot more code. There are many examples of code still being worked on. It actually fills the gap I’ve felt in Agile Software Development of seeing the actual coding steps, test by test. The last chapter shows a really thorough (and actually quite mesmerizing) example of refactoring, with each change explained beforehand, including tests and alternatives considered.

In Agile Software Development, there were a few co-authored chapters. In Clean Code Uncle Bob took this a step further. Almost every chapter was written by a different author, each of very big caliber in the Agile and Software Craftsmanship world. This really resonated with me, because it’s kind of a “many in one” deal, and because I could actually hear a different tone in each chapter, and yet all were in harmony with the motive of clean code.

I think this is truly a masterpiece, and after reading, would recommend it to be read before Agile Software Development. Due to its greater technicality and the fact it’s quite new, it makes a really good read for developers, and it will have an effect on your coding a few pages in (pages! not even chapters).

The only thing that bothered me was that in the last chapter (which is also the best) I had to, as the introduction warned me, flip back and forth quite a bit, which was a bit hard at first since I’m not used to reading code on paper. I’d really love seeing some interactive version of this, but regardless of that, the book is really good.

I can’t recommend enough this concentrated piece of wisdom and experience.

Stay tuned, a review of Apprenticeship Patterns is nigh.

You should subscribe to my feed and follow me on twitter.

How often do you get to work along some coding superstar that’s been at it for decades? If you’re anything like me, the answer is “never”. That’s why I’ve recently decided to go after books that are aimed to fill this gap exactly. The latest is “Agile Software Development: Principles, Patterns, and Practices” by the one and only, Uncle Bob (the previous is “TDD by example”, which gets 5 stars from me too).

It’s like coding with the Uncle himself

The thing I liked the most about the book, is the way it walks through (relatively) huge amounts of code. Uncle Bob shows several programming problems and walks through his design process and the implementation of the interesting parts. Reading it (even though it was written almost a decade ago) you can’t miss the fact the author has so much experience. Whenever I tried coding a solution myself before reading on, I later found out exactly where I went wrong because he somehow managed to cover every decision I made.

When I say it’s like coding with him, I really mean it. I don’t know how, but whenever I looked at a code sample I didn’t like for some reason, I was astonished to read “You may be wondering why I did X” the next paragraph. And, maybe less fun, is when I read something, totally agreed with it, and he went on to explain why it sucks.

The feeling throughout reading the book is that you get to pair with one of the best software craftsmen ever.

You get experience in every paragraph

A big part of the book is dedicated to talking about XP and design patterns. I’ve read several books about both and yet I didn’t find those parts in the book redundant. The reason is because Uncle Bob has managed to put a few grains of experience into whatever he talked about. Even though I’ve coded my fair share of Factories, he made me realize a few interesting concepts about them. And although I’ve done Visitors, I suddenly am a bit in love with them (which means I have to fight myself extra-hard not to introduce them everywhere).

If you don’t have people around you that care about coding a lot (enough to send out awesome Clean Code wristbands, one of which I own) you’ll quickly grasp what I’m talking about. The whole writing is of an experienced mentor (which might explain why his company is called “Object Mentor”).

It simply changes the way you look at coding

Having gone through the SOLID principles, my whole designing process and way of thinking has changed. I can’t think of a sane developer that will refuse to put his hands on a set of principles that the best coders of the past decades have deemed as necessary for quality code.

Do yourself a favor and get your hands on this piece of software-craftsmanship gold-mine!

Stay tuned for the next part of this series, Uncle Bob’s Clean Code!

You should follow me on twitter and subscribe to my RSS feed, it’s free!

I’ve just finished reading Kent Beck’s TDD by Example, and man, what a great reading that was. It was so good, I’m gonna put it in my top 10 books list (accompanied by other classics, like The Pragmatic Programmer and Beck’s probably most known book, Extreme Programming Explained).

I’ve been doing TDD (to an extent, say at least half of my production code) for the past 4 years or so. I was pretty sure I knew what the deal is, and there’s no doubt it’s paying off. I didn’t think there’s a lot more for me to learn. I thought to myself, “how much better can it get?”

Lately, a lot of anti-TDD posts have been popping up on the interweb, which made me ponder a bit more about it. Furthermore, I’ve been exposed to more casts and the likes regarding TDD that made me think I just might be able to squeeze some more fun from my TDD.

That’s when I realized my work place has a copy of the “TDD by Example” book. I’m a sucker for books, and having liked Kent’s writing so far, decided to add it to my book queue, and actually pushed it all the way to the top.

It’s a very light and fun reading. The style is a lot to my taste, and easy to follow (even for someone whose mother tongue isn’t English). But other than the pure writing style, there are just so many gold nuggets in that book. Just about every page has something golden.

Most coders will never have access to such a super-star-coder, that literally changed the way we work. This book is a great way to rub off some of that genius. The simplicity in which design decisions are explained is astonishing. I myself typed along all the code in the book as I read it. Sometimes I tried writing ahead, comparing my results to Kent’s, and every time I was surprised. The cleanliness he shows, the delicate thinking, truly amazing stuff.

Other than that, given all the critisicm that’s been direct at TDD lately, the book explains in great detail what are TDD’s objectives, how it can be used productively, and what should you expect of it.

And now, the really good stuff. The major pay-off I’m seeing currently, is that I found out a few ways to make TDD even better for me. Yes, the bug count is already low, but you can get it even lower. Not just that, picking up a few tips from Beck makes me think about the design of my code better, and simply make you a better coder.

Actually, most of my TDD ”education” is informal. Someone once explained the concept to me, and with time I refined my ways a bit using experience gained and knowledge found on the web. Reading the book on TDD, you find there are names for things you’ve already been doing, but never given much thought to. Moreover, there’s just that thing about naming things – sometimes it simply makes you understand them better.

I think I’ll stop writing any further, before this will make me look like I’m stalking Beck. But really, you should read this book. It’s so good, I’m going to order my own copy simply to have it around. Yes, that good.

You should follow me on twitter here.