Sunday, September 23, 2012

Reasons to Go to Øredev, Reginald Braithwayte

Øredev is selling tickets like never before. For the first time ever we believe we will sell out all days and not just Wednesday, like last year. So if you still haven't bought a ticket it is time to do it now.

To help you along the way I'm going to present you with another reason to register, Reginald Braithwayte

Reginald has recently released some books through leanpub, such as What I've learned from Failure and How to Do What You Love & Earn What You’re Worth as a Programmer.

I first came in contact with Reginald through the blog, Raganwald, where he wrote about programming, testing, agile, work, etc. On this blog, you can find gems, such as:

The Narcissism of Small Code Differences where he writes about different styles of programming and why and why not they matter.

Why Why Functional Programming Matters Matters?, a commentary on the paper "Why Functional Programming Matters". It discusses topics such as "Separation of Concerns" and "Responsibility Driven Design".

The significance of the meta-circular interpreter discusses meta-programming, DSLs, and why it is important for a language to be self hosted.

Programming conventions as signals, a blog about why it is important to write in a style that signals the intent of the code to other programmers.

More recently he started another blog, Homoiconic, hosted on Github. In this blog you can read about functional programming in Javascript, Coffeescript, etc.

Some of my favorites are:

Method Combinators in CoffeeScript where he uses function combinators to create AOP like constructs like before, after, around, etc.

Captain Obvious on JavaScript, examples using functional programming in Javascript.

Reg will be giving a keynote on rebellion and a talk on jQuery Combinators Don't miss him at Øredev.

Sunday, September 16, 2012

Enthusiasm, the Invisible Key to Success

Nothing great was ever achieved without enthusiasm. -- Ralph Waldo Emerson

The quote from Emerson is a classic but, even though it is true, we don't put enough effort into encouraging enthusiasm.

So, why do I say that enthusiasm is the key to success? There are a two reasons for this. The first is happiness, enthusiastic people are happy.


Happy people are better at creative problem solving. -- Martin Seligman, Authentic Happiness

In positive conditions, mental images appear rapidly, with great variation and our thought process flows quickly. -- Antonio Damasio, Descartes' Error

Happy people are more likely to have insights. -- David Rock, Your Brain at Work


The other reason why enthusiasm is important is the amount of time spent on the issue that we are enthusiastic about. When I write the amount of time spent on the issue, I mean two different kinds, conscious and unconscious time.

Conscious time is the time we spend actually working on the task at hand. Enthusiastic people will spend a lot more focused time on the task than on something else like Twitter, Stackoverflow, or Facebook. This is of course great but, this is not the most important time.

Unconscious time is the most important time. This is the time we spend not actually working on the task, but doing other thing such as taking care of our kids, enjoying sports, beer, or even sleeping. As I wrote about in Rationality is Overrated, our unconscious mind has a lot more capacity than our conscious part. An enthusiastic mind will work overtime, for free, on any task. This is not something we should take lightly.

The enthusiastic approach may not always be the most sensible approach. This is OK, enthusiasm is more important than sense.

What is sensible about open source? Open source is created by enthusiasts and the code usually has a lot higher quality than enterprise code.

Encouraging Enthusiasm

If you believe my above reasoning, it is easy to see why encouraging enthusiasm is important. So how do we do it? We do it by trusting people. We do it by letting the people working on our projects do it in the way that they find best. This is what is talked about in the Scrum books about hyper-productive team's. It has little to do with Scrum and everything to do with enthusiasm and autonomy. Autonomy is one of the major driving forces of motivation in Dan Pink's book Drive. Hyper-productive teams are enthusiastic teams and they are hyper-productive because their brains, conscious and unconscious spend more time on the project than any Death March project is able to force in.

But, it is not enough to just allow people to be autonomous, it is also important to encourage everyone on the team to become enthusiastic about what they do.

Everyone should be encouraged to do the tasks they are enthusiastic about and, they should also be encouraged to reframe the tasks they are not enthusiastic about into tasks that they are enthusiastic about. This is a lot easier than it sounds. One way to do this is to encourage people to create tools that allows them to automate what they find boring. Writing automation software is not boring, in my opinion.

There are of course other things that will help you and your team build your enthusiasm. Find them and encourage them.

Discouraging Enthusiasm Dampening Behavior

There are three things that kill my enthusiasm. They are unnecessary process, bad code and deadlines.

Unnecessary process

You can almost tell from the name that it is unnecessary :). Being unnecessary means that it is also an enthusiasm killer. Process should be minimal. Challenge every part of the process, often! An unnecessary part may sneak in without anyone thinking about it at the time.

Bad Code

You may have heard of the broken window theory

Applied to code, it basically says that if you allow bad code (broken windows) in your application, eventually the whole application will be broken, since the bad code will serve as an example and give silent permission to write more bad code. This is a theory that I believe in.

But I also have a corollary to this theory, I call it the pile of shit theory.

The Pile of Shit Theory, if you leave crappy code in an application for too long, the stench will eventually drain the enthusiasm from the developers working on that code.

If the crappy code cannot be completely isolated from the application, it must be refactored or the enthusiasm for the entire application will eventually disappear, and along with it the developers.

There are lots of other things that may dampen yours and your teams enthusiasm, try to identify and eliminate them as soon as possible.


I have written extensively on my thoughts on deadlines in No Deadlines, so I'm not going to dwell on it too much this time. Suffice to write that deadlines, usually, is incompatible with enthusiasm. Since deadlines produces stress, and stress puts us out of flow.


Enthusiasm is an almost unlimited resource that we must take advantage of. How much of your day do you spend on tasks that you are not enthusiastic about? It is time to stop doing that and to become a happy, productive enthusiast.

Nobody grows old merely by living a number of years. We grow old by deserting our ideals. Years may wrinkle the skin, but to give up enthusiasm wrinkles the soul. -- Samuel Ullman