First impressions of CoffeeScript

I first heard the word CoffeeScript banded about by a few people in the agile circles I run in a while ago. I heard that it was a language that compiled down to JavaScript but was more succinct and had better syntax. This instantly peeked my interest.

I've been coding Javascript for about 14 years and frankly I've always hated it. The advent of JQuery has made it more bearable, but it hasn't changed my feelings about JavaScript and don't get me started on JavaScript inheritance :)

I figured that anything that could improve on the syntax would be a good thing, so I decided to give it a shot.

Scott Hanselman recently posted about a plugin for VS.NET, called Mindscape Web Workbench, which allows realtime compilation of CoffeeScript to Javascript so I installed it and was off to the races.

Whenever I learn a new language I like to reimplement code I have written previous. This allows me to get the syntax down without worrying about logic. In this case I decided to rewrite a JQuery plugin, in our product at work, that I had worked on in the past.

I have to say that after some initial high hopes and early wins I'm rather disappointed.

I'm disappointed because the CoffeeScript syntax isn't too far removed from the way our Javascript is structured already and only slightly more succinct. We make heavy use of Knockout which is an MVVM framework. I'm not going to go into depth about Knockout, but if you want more information you can visit the Knockout website.

Here's an example of how our Javascript models are structured:

var exampleModel = {
    selection: ko.observable(""),
    text: ko.observable(""),
    isEverythingEntered : function () {
        return this.text().length > 0 && this.selection() > 0;
    }
};

Now here is that same code in CoffeeScript:

exampleModel:
    selection: ko.observable("")
    text: ko.observable("")
    isEverythingEntered ->
        this.text().length > 0 and this.selection() > 0

As you can see, they are very similar. This is a contrived example, but the more complex ones aren't any different.

The pros as I see them so far are as follows:

• No more missing semicolons at the end of a line. Though Firefox and Chrome are robust when it comes to malformed JavaScript, IE isn't and will throw script errors if there's a missing semicolon's. Same goes for additional commas at the end of a block.
• -> looks far nicer than having to write function() { }

The cons are as follows:

• It relies on tabbed indenting. The rest of our codebase is space indented. At this time I'm not sure if this is a problem with CoffeeScript or with Mindscape Web Workbench.
• I'm not a fan of the if then else syntax instead of a ternary operator.
• Large Javascript files cause VS.NET to lag a bit. This isn't to do with CoffeeScript, but to do with the plugin.

Right now I'm not sure the pros are enough to adopt CoffeeScript.

I'm curious what your experiences are. Am I missing something?

Is it easier or harder these days for kids to get into software development?

I'm going to show my age for a second and post my first crotchety old man post. I first started learning how to program almost 30 years ago when I was six years old. I don't claim to have written anything interesting at that age, but it started me on a life long journey. Fortunately I had access to something that kids don't easily have access to these days, a built-in programming language for their computer.

When I was six my parents bought my brother and I a BBC B Microcomputer with a separate tape drive and a couple of games. I instantly fell in love with it and would play games for hours. This isn't to dissimilar to kids now but there was one thing that changed everything for me and that's boredom.

Even though I loved playing the games I had I got bored with loading them from tape. This was a long and error prone task, I'd often have to rewind and press play again and again to get a particular game to work. After a while I decided to see what else the machine could do, but the only thing I had was the built-in basic interpreter available on the command line. So I experimented and failed, but learnt a lot by trial and error.

These days most kids have the ease of loading games on demand and there's no lack of games available. You don't even need a computer anymore. Does this lead to a lack of inquisitiveness of what the underlying platform can do?

Yes there are plenty of kids who want to write computer games, but how many have the resources to do so? If you're coding on a Windows platform until a couple of years ago you'd have to fork out for a full version of Visual Studio. Fortunately there are free express editions of Visual Studio available and have been since 2005. How many kids know about this though? Should Microsoft bundle it with all version of their operating system?

There are other alternatives, free downloadable compilers or interpreters for various programming languages. Another option is to install Linux and use something like gcc or g++, but these options require fore-knowledge.

Anyway these are just some random observations I've made over the years and may not be valid anymore.

What do you think? Am I wrong?

Working until the eleventh hour of the sprint

Over the years I've seen many types of team. Some teams believe that they have to cram as much in to a sprint as possible and work up to the 11th hour to get it all done. I used to think that way too. This can lead to, amongst other issues, the team working too all hours on the last day of the sprint. This is especially true if there have been unforeseen issues.

If you're able to do that successfully each sprint then more power to you, but I prefer a slightly different approach.

Though the term sprint suggests that we should hurry though as many stories as possible (while meeting the definition of done), I view the sprint as agreeing to a set of stories and creating them the best way you can. i.e. making them awesome (I know that sounds a little cheesy but couldn't think of a better word).

The approach I prefer is to build a little slack into the sprint. This means that the final day can be used slightly differently.

A little slack gives the team some time for innovation and learning, plus allows preparations for the sprint review. It also gives a little break from the constant slog.

Some people may consider this waste as it's time that could be used to potentially work on more valuable stories, but I look at it as making the product and the team more awesome.

What do you think?

Software development career tip: Find yourself a mentor

A few weeks ago someone asked me the following question:

If I was to offer one piece of advice to someone considering becoming a software developer, what would it be?

At the time I answered that they should expect to never stop learning. Things in the software development world are always changing and if you stop learning you can easily stagnate.

Though I still consider that good advice if I'm asked that again I think I'll change my answer. My advice is simply:

Find yourself a mentor.

Usually a mentor will be a more senior developer, tester, agile coach etc within the company you work for. I know it's hard to ask for help, but don't be shy. Speak up and actively ask for mentoring.

I never had a software development or agile mentor. i.e. someone to take me under their wing, help point me in the right direction. I've mainly learnt everything by myself, via an occasional course and through talking to colleagues. That's not to say I don't value any of these methods, it's just I feel that being mentored accelerates learning.

After being a mentor to other developers, I've seen how quickly they've learnt techniques that I took many years to even discover and use properly. This plus their own self learning, eventually allows the student to surpass the master.

Though I've implicitly known this for years, I've only just recognised it and I recognise that I also could do with a mentor myself when it comes to coaching agile teams. I'm kind of using forums and social networking to fill this gap, but I don't feel like it's quite enough. If anyone wants to help me out let me know ;)

I sometimes wonder where I'd be if I had had a mentor throughout my career, but that sort of thinking is counter productive. Does it upset me? Not really, it's nice to see others build on the knowledge I've bestowed upon them. If I'm really honest I sometimes have a twinge of regret or jealousy, but it's fleeting and I'm only human.

What are your experiences in being a mentor or a mentee?

The daily standup and flexible working hours

As mentioned in my post about The implicit bias with flexible working hours, I'm a fan of having a certain amount of flexibility in working hours.

Though some companies can be uber flexible and allow people to set their own hours, there are several limitations. The one I'm going to focus on today is with the daily standup meeting.

I'm going to assume that you're familiar with the daily standup meeting so I won't go into it in detail. In case you're not here's a great article about it. The Daily Scrum Meeting

The daily standup meeting happens every day at the same time, but if a team member turns up late then it isn't as effective. That team member won't hear what everyone else has done or will do, and won't provide that information to the team.

If the standup meeting time always changes to happen after all team members are in the office, the team is prone to forget to do it.

Naively in the past I've performed two standups, one with the team members that are there and one with the individual who comes in later. This is not a good idea and didn't really benefit anyone.

If you do allow employees to set their own working hours, I suggest a slight change. Let everyone know that they are expected to attend standup everyday. Talk to the team and ask them to agree on a time for the standup meeting. Also explain the reasons why it's important for all team members to attend.

My personal preference is for companies to set core working hours where everyone is expected to be in. I've found that this gives some flexibility, but also gives the team a good amount of time working together. The hours that all team members are in the office are the most productive.

I'll be going into more depth about core hours versus employee set hours in an upcoming blog post.

Thoughts?

The implicit bias with flexible working hours

I'm a big fan of flexible working hours. I'm one of the few that gets in early and leaves early due to family commitments. I do seem to be in the minority as most techies seem to prefer to come in late and leave late. I also don't have to stress about being late, because my employer knows that I'll make up those hours.

One problem I've discovered being an early starter is around crunch times. I've found that there's an there's an implicit pressure and bias by the team to have everyone working late until the same time. This isn't so much of a problem for late starters, but for early starters they may have already put in 2 to 3 hours of work before others arrive.

All I ask for is teams with flexible working schedules accept that around crunch times early starters might stay late, but not as late as their later starting colleagues.

Thoughts?

Is the daily standup good for the brain?

A few days ago I came across an article on Psychology Today called Is Your Brain Asleep on the Job? which talks about how doing the same thing day in day out uses the same neuronal pathways over and over, eventually forming ruts. It goes on to discuss ways of waking up your brain by challenging it, but right at the end of the article I came across the following quote:

Another way to wake up your brain is to create short-term goals for each day (or task). These tell your brain what you want it to focus on, bringing it to fuller attention. Your brain likes having a set of concrete actions to perform. That's why having and reviewing a list of short-term goals, and the tasks required to meet them, works so brilliantly. Your brain happily signs on as your taskmaster, but it's up to you to create the tasks that matter and to keep your brain alert and focused on achieving them. It works because goals wake up "sleeping neurons" and strengthen and increase the firing of neuronal synapses

This instantly made me think about the daily standup. Every day we create short-term goals and provided we stay focused we are helping our brains.