Have been hit by the functional programming bug yet? If you read around the blogsphere and listen to podcasts lately, you’ve surely been exposed to the revamp of functional programming languages all over the place. Haskell, Erlang, Clojure, F# will likely gain a fair share from the usual suspects (Java, C# in primis) at least in some well defined areas of the business logic.

There are countless posts around highlighting what’s great (and not so great) about functional programming, so I won’t repeat those arguments here. What I am offering is just a few pointers to F# resources that might help you getting familiar with .NET way to functional programming.

Screencasts

Screencasts are a good way to get a feeling of what functional programming (and F# in particular) look like and why they should matter to you.

• An Introduction to Microsoft F# by Luca Bolognese (PDC 2008). Excellent video, it takes a bit more than one hour.
• F# and Functional Programming in .NET (2009) by Don Syme (one of the fathers of the language). Another great video from the mind behind F#.

Free Documentation (Books, White Papers)

When you are ready to get your feet wet with the languages, there are a few free resources that are great to get you started:

• The F# Survival Guide:
• F# Programming: from Wikibooks

Commercial Books

Once I am ready to get serious about a language I feel a need a real book to get deeper into the details. Here are a few titles that seem to get great feedback from the community. A search with Google will reveal more and new titles are expected to be published shortly as the language is starting to get traction.

• Expert F# Hardback (Expert’s Voice in .Net): This is the book I am using right now after going through the (shorter) free books above. A new version is about to be released.
• Beginning F#
• Real World Functional Programming: With Examples in F# and C#

Other Web sites and Blogs

• Microsoft F# Developer Center: Microsoft home page for all things F#, with tons of links and resources. That’s the place you want to go to download the tools and add-ins for Visual Studio 2008 if you, like me, haven’t switched to Visual 2010 yet.
• Hubfs: News, blogs and forums dedicated to the language.
• The FSharp Wiki: Great collection of links to online resources.

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.

The new year has just started and it’s time for me to share my professional life resolutions for the upcoming year.

Through books, articles, blogs, podcasts, one hears about that language, or that technology, or that process which would be great to try and learn. Unfortunately, since the spare time is not infinite, one has to make choices and concentrate on what might give the best return on investment in the short/medium term. The following are the two or three things which I have chosen to dive in this year:

Read the Blue Book

Domain-Driven Design by Eric Evans is one of the best book that I have come across on software design in a while. Not always an easy read (some say it’is “dense”), I am going through it slower than usual: every chapter is full of sound advices and deep concepts that take a while to sink in.

Luckily in my current project I will have the opportunity to apply many concepts from this approach. For this reason alone, this makes to the top of my list for 2010.

Learn Ruby

2009 has been for me the year of C#. The Pragmatic Programmer suggests to both to learn a new language every year and getting familiar with one scripting language. Most experts seem to agree that learning a language with a different paradigm from the one you use everyday is a big plus. Martin Fowler (who favors Ruby) states that:

[...] programming languages do affect the way you think about programming, and learning new languages can do a lot to help you think about solving problems in different ways. (It’s important to learn languages that are quite different in order to get the benefit of this. Java and C# are too similar to count.)

I am not expecting to become proficient with Ruby in the near future (after all, I will still be using C# in my every-day at work). However from what I have seen so far it really looks like a great language to learn, so I am looking forward to it.

Play with Subversion

In my previous job at Motorola I was developing in a mixed Unix and Windows environment; Rational Clearcase Multisite was the company-wide version control tool. Clearcase is a real heavy weight, and probably one of the few tools that can handle teams of hundreds of developers located anywhere word-wide.

When I landed my current job I had to switch to the much more limited (and widely hated) Microsoft Source Safe (hey… always better than no version control at all, right?) Luckily, rumors has it that we might soon migrate to Subversion.  Subversion is widely used in the open source community and I guess I’ll need it once I start playing with Ruby and downloading libraries etc…

Other Books to Read

Beside the blue book, there are a few other books that I plan to complete reading this year. I have already started Clean Code and Pragmatic Thinking and Learning. Next on my list is Working Effectively With Legacy Code and Agile Estimating and Planning. I promised myself not to buy any more book before I clean my current queue!

Stuff Left for 2011

As I mentioned, there are so many other things I would love to investigate and play with, but there is only so much time available, considering that 2010 will bring in .Net4.0 and C#4.0 that will surely be a priority.

Therefore, the following I guess will have to wait till 2011:

• Learning a functional programming language (possibly Haskell or F#)
• Getting familiar Domain Specific Languages (Martin Fowler is preparing a book on the topic)
• Play with Android and/or iPhone development
• The Next Big Thing from 2010!

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.

Hello everybody and welcome to my blog!

I have been thinking about starting a blog for some time now, and the new job that I have landed has turned out to be a good occasion to share with you all my experiences in the new and fascinating world of enterprise applications on .NET.

In this first post I feel I need to spend a few words on the blog’s banner saying “Chased by the Silver Bullet”. So, what does that mean?

You might have already heard about “No Silver Bullet”, one of the most famous papers ever written in the history of software engineering. The essay is included in one of my all-time favorite books: The Mythical Man Month, by Frederick P. Brooks.  Written back in the mid ‘80s, the topics touched in this book are still relevant today, mainly because the author concentrates more on the human factors of software development than specific technologies.

Chapter 16 from this book is “No Silver Bullet – Essence and Accident in Software Engineering”. The central proposition is that

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

In other words, writing good software is hard, and most likely it will always be. There will always be projects which are late, requiring double resources and shipping half of the planned features.  Irrespective of new technologies, languages, tools; we’ve all been there. Yes, new processes and platforms can make our life easier , but they affect only what Brooks describes as accidental aspects, not the essential ones which he identifies in the

specification, design and test of this conceptual construct [the software], not the labor of representing it and testing the fidelity of the representation […] Building software will always be hard. There is inherently no silver bullet.

You can find the complete paper here (pdf).

Aren’t we all as developers (and potential buyers of tools/courses/seminars/etc…) always chased by yet another silver bullet, or the new fad of the moment with its promise land where productivity blooms, deadlines are met, customer expectations are exceeded?

I believe that the very people developing the software will always matter more than anything else (I agree with the agile manifesto here). Hence the need to continuously improve, to learn new things every day and to share all those little discoveries within your network of coworkers and friends. That’s the reason behind this blog which I hope you’ll enjoy!