Since you are reading this blog I assume that you are a software developer, or more in general a “knowledge worker” as Peter Drucker refers to the person “who puts to work what he has between his hears rather than the brawn of his muscles or the skill of his hands” in his excellent book Effective Executive.

And if you try to keep up to date by reading books, blogs, listening to podcasts, etc… I sure don’t have to tell you how difficult it is staying on top of new technologies, frameworks, languages which come out quicker and quicker. It’s sure impossible to keep up with everything.

Trying to come up with some new ideas on how tackle this issue, I have picked up the book Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt with high expectations, having loved The Pragmatic Programmer (see my review of that book here) where Andy Hunt was one of the two authors. And I must say that I have not been disappointed: Pragmatic Thinking and Learning is another great book.

Let’s have a quick look to the contents.

From Novice To Expert

The book first focuses on describing a few phases one goes through in his learning journey. The Dreyfus brothers have tried to formalize the steps to reach the expert status on a given skill (like practicing a sport or programming using a particular language) in the following way:

• Novice: you start from here and for basically everything you have to do you need a “recipe”.
• Advance Beginner: you now start trying things on your own, and need reference documentation (think of a list of API)
• Competent: you have more initiative, can troubleshoot existing problems and solve new ones.
• Proficient: at this stage you are more self-conscious of your own skill and want to understand the larger picture. This feedback is vital for your continuous improvement.
• Expert: at this stage you keep looking for better ways of doing things. You tend to work from intuition as opposed to a fixed set of rules and reason: you just ten to “feel” what’s right in any given situation.

How Your Brain Works and How To Make The Best Use of It

The model put forward of your brain here is that of a “dual core” CPU. But the two halves don’t work the same way:

• L-Mode: this is your linear mode(traditionally associated with the left hemisphere): analytical, rational, verbal. This is perhaps the part of our brain that we are most familiar with in our day-to-day activities as software developers.
• R-Mode: intuitive, analogic, non-rational. These are the traits most commonly associated with artists.

This major section of the book explains why, as a knowledge worker, you need both modes to fully exploit your abilities, and gives tips on how to “shut up” the L-Mode for a while so that you can engage more the R-mode.

It then goes on to help you “debug” your thinking process, introducing several cognitive biases (things such as “self serving bias”, “hawthorne effect”, “false memory”) and explains that many of your hard-coded thought patterns might just be due to the generation you belong to (are you in the Baby Boom Generation, in the Generation-X or in the Millennial Generation?).

Learn to Learn and Gain Experience

The book then concentrates on the best practices to learn:

1. You need to set SMART objectives for what you want to reach. Having a plan will keep you focused.
2. You need to consider your skills as a knowledge portfolio. You need to diversify the areas you decide to invest in and dedicate some quality time to it regularly (which requires planning some time in advance: trying to find some free hours here and there simply doesn’t work…).
3. You need to discover how you learn best. Do you prefer books and videos (visual) or podcasts (audio)? Consider joining a study group,
4. Use advanced learning techniques such as SQ3R, or mind mapping. Teach to others.
5. We learn best by doing: explore, play (= have fun) with the concepts, gets your hand dirty. Experiment and don’t be afraid to make mistakes, possibly in a non-stressful situation (you don’t want to have the pressure of a “real” work project).

Keep the Focus

The last part of the book has is somehow lighter and it’s dedicated to ways to increase your focus and attention. The author touches upon different topics from meditation to productivity tricks: if you have been exposed to productivity blogs such as Lifehacker you are like to be familiar with most of these already

Conclusions

This has really been a fun book to read and I whole-heartedly recommend it. I have gone back to it quite a few times already after reading it from cover to cover.

Each small chapter contains a “Next Actions” section with exercises and goals for you to try out and throughout the book there are tons of references if you are interested in a particular topic and want to dig more.

It used to be that all you needed to perform your job was “The C Programming Language”. That’s not the case any more.

If I had eight hours to cut down a tree, I’d spend six hours sharpening my ax. — Abraham Lincoln.

Why Should You Care About Podcasts

There are many ways to keep up to date to what’s going on in the software community. Blogs, books, magazines, conferences, discussion groups, mailing lists, you name it… So, should you care about podcasts?

If you are anything like most of us mere mortals, you’ve already come to realize that there are way too many things that you would like learn and only so many hours in a day. Podcasts allow you to squeeze some more “learning time” from an otherwise compressed schedule.

I especially love to listen to podcasts on my running sessions. On the other end, I have found that I don’t usually care for them while commuting to and from work: I need some time to relax listening to good music before and after a stressful day. Your mileage might vary.

The podcasts listed below are basically the only one which I am subscribed to on iTunes. I can’t keep up with all the shows, so I try to cherry pick from the themes that are closer to my day to day work, occasionally listening to topics I am not familiar with just to see what’s going on.

A few other podcasts did not make my selection, like Elegant Code or Stackoverflow: after listening to a few episodes I found that they simply were not my cup of tea.

I especially love shows which have a clear focus, the right amount of “small talk”, and where the host(s) have a good understaing of the subject matter. Again, YMMV.

05 – Deep Fried Bytes

At number 5 we have Deep Fried Bytes, hosted by Keith Elder and Chris Woodruff. The schedule is not strict, roughly one or two shows per month. Too bad because the content, almost exclusively on Microsoft technologies, tends to be top notch.

Favorite Eposide: Episode 35: Why Comments Are Evil and Pair Programming With Corey Haines.

Content:
Signal-to-noise ratio:
Frequency:

04 – Hanselminutes

At number 4 we find Hanselminutes, the podcast of the famous Microsoft developer geek Scott Hanselman. If you don’t know him, he’s the name behind one of the most followed blog for develpers.

His shows tend to be on the short side (usually around 30 minutes), but they are usually really focused. He’ll usually talk about .NET technologies.

Once in a while you can lift your spirit with one episode of the Hanselminutiae series, which are more unstructured and tend to be a conversation about nerdish stuff and gadgets with some geek guest.

Favorite episode: Uncle Bob Martin: SOLID, this time with feeling.

Content:
Signal-to-noise ratio:
Frequency:

03 – Herding Code

At number 3 we have Herding Code, hosted by K. Scott Allen, Kevin Dente, Scott Koon, and Jon Galloway. Four hosts tend to produce a slightly lower signal to noise ratio compared to other podcasts, but the content is usually well worth it. Again, you’ll mostly hear about Microsoft technologies here.

Favorite episode: Herding Code 51: Greg Young on Our Grand Failure – Thoughts on DDDD

Content:
Signal-to-noise ratio:
Frequency:

02 – DotNet Rocks

At number 2 we find what’s arguably the best and longest running podcast on .NET technologies. DotNetRocks, hosted by Carl Franklin and Richard Campbell and now at his 523 eposide, usually issues a new show twice a week.

At the beginning of every new show, there’s a short section (a couple of minutes or so) named “Better Know Framework” in which they “shine some light “on some class of the .NET Base Class Library.

If you have time for only one podcast and don’t care for other technologies/platforms, then this is probably the podcast you should be listening to.

Favorite episode: Panel: Is Software Development Too Complex?

Content:
Signal-to-noise ratio:
Frequency:

01 – Software Engineering Radio

At the top of my list we have a podcast that is not devoted to .NET technologies.

Software Engineering Radio, usually hosted by Markus Völter, is your 10,000 feet view on what’s going on in the software industry: new languages, patterns, processes. And evergreen topics like OOAD, components, architecture, etc…

The shows are usually extremely focused on the topic to be discussed, and Markus shows a remarkable easiness moving from one subject to another. He surely prepares a lot before the shows; his questions to the guest are usually spot-on and he has a way of rephrasing the concepts exposed by the experts that really helps your understanding.

The show has a fortnight frequency, therefore I usually don’t miss a single show. I actually downloaded a lot of old episodes: since they are not so strictly connected with current-day technologies, they usually stand the test of time pretty well.

As an added plus, a show usually last about 1 hour which is perfect for my workout sessions

Favorite episode: Software Craftsmanship With Bob Martin

Content:
Signal-to-noise ratio:
Frequency:

I recently embarked on a journey to read (or re-read) all the great classic books in the software literature.

The Pragmatic Programmer is one of those books which is usually included in the recommended readings for a software developer, and deservedly so. The book, released in 1999, has been so successful that the two authors, Andrew Hunt and David Thomas, have since created their own publishing company, the Pragmatic Bookshelf (with titles spanning a broad range of programming topics).

This book must really have been a breakthrough when it hit the bookstores about 10 years ago. 1999 is one year before Kent Beck released his seminal book Extreme Programming Explained: Embrace Change which exposed the agile software process to the masses. Both Andrew Hunt and David Thomas originally signed the Agile Manifesto, together with Kent Beck himself and a few others, and it shows. But it would be dismissive to describe this as a book on agile since it’s much more.

The book is structured as a series short 46 sections. Each section has challenges and even exercises where appropriate. It touches on design concepts such as orthogonality, decoupling, DRY (which it coined), Domain Specific Languages, Design By Contract, Metaprogramming, Refactoring; it has pages on process topics like build automation, “design to test”, test automation, estimation, requirements collection.

But where the book really shines is where it shows you how to “become a better programmer” (today we might say a software craftsman) and to take pride from it.

The pragmatic programmer is an early adopter, is inquisitive and realistic, and tries to be “familiar with a broad range of technologies and environments“.

The pragmatic programmer takes responsibility, values quality but recognizes when the software is “good enough”. The pragmatic programmer is a continuous learner (the “learn at least one new language every year” advice is often quoted), thinks critically about what he reads and hear, and knows how to communicate. The books explains how you can build these qualities.

The sections that I enjoyed the most is when the authors discuss about tools: the pragmatic programmer prefers working with plain text (the book itself it’s been written from XML transformed into TeX), masters a shell (command line) which he/she can program, knows at least one text manipulation language (e.g. Perl) and how to generate code from metadata.

Even though the recent reprints have links to later tools like JUnit, Ant, etc… still a few parts of the book begin to show its age. For example the authors suggest to pick one text editor (e.g. Emacs or VI) and become a power user (not just know the keyboard shortcuts but also how to extend it to suit your needs). There used to be a time when you could spend your whole working day inside Emacs: you could edit and build your programs, open a shell, handle emails and browse newsgroups, edit text documents (with LaTeX for example), even play games. As much as I love Emacs, I believe today it’s virtually impossible to beat the productivity gains you can get with specialized IDEs like Visual Studio or Eclipse, with their intellisense and plug-in ecosystems.

All in all, the Pragmatic Programmer is easily one of the best book on software development I have ever read. It has really inspired me to continue my journey to become a “better programmer”. Thanks to this book, I have now in my action list: learn a scripting language (Ruby?); learn a functional language (F#?); learn how to use a shell in the Windows environment (PowerShell?); read a book on usability; read a book on the human side of software development (“Peopleware”?). A lot of things. A lot of fun ahead.