Learning to program

Tim O’Reilly has an interesting post on the O’Reilly Radar where he references some discussions they have had when it comes to learning, and in particular learning to program.

In essence it requires practice, and we need to work hard at it. There is however a bit of a paradox here. If you are going to practice that means doing the same thing over and over again with small variations to get good at it. I see in the discussions that it is often compared to learning maths, and I have no doubt that my utterly horrible math skills stems from the fact that I never took the time to sit down and practice. But the repetitions is difficult when it comes to software, as it is written to avoid doing repetitive tasks and we always learn that one of the basic principles of software development is DRY.

The way we usually work doesn’t really foster continuous repetition and learning either. When you are working in a project the solution is created and then you move on. The next time you get to try the same thing with a little twist from what you learned the last time around, is when the next project kicks off. With the worst projects around this means 2-3 years between each repetition. And according this definition of mastery you’re going to have a hard time reaching that:

According to Dizzy Gillespie, it takes ten years of practicing your butt off to achieve Mastery. His statement has been backed up by scientific research which shows that to reach a very high state of mastery, a task should be repeated about a million times, which takes about ten years. Better get busy! – (Sound the Trumpet, pp 67-68)

Related to practice is also another pet peeve of mine: We need to practice at it and use real OO. Usually we’re not good enough at using the power of our OO languages like encapsulation and separation of concerns. You can of course debate whether OO is the best way for developing software, but if you are using an OO language we need to get better at the basics. I believe that if we practice these basics more it will give us big returns in regards to quality and cost of systems. Way too many systems are built around POJOs acting as data carriers with all kinds of logic scattered all over the system.

So how and when to practice? Most companies should have structures for facilitating this during work hours, but ineveitably you will also need to spend some of your own time. One thing I like doing is participating in small projects. The smaller the project the sooner I get to move on and try a new angle on how to do systems development. Other ways may be to participate at a code dojo, or contribute to Open Source projects. I haven’t really tried a code dojo yet, but it sounds like a great idea. How would you practice?

The bottom line is that we can not read about something like programming and get good at it. Mastering software development requires practice and we need to focus on finding, using and creating spaces for practice.


Moving on

As of january 2009 I’m moving on from BBS which has been my current employer.

It has been a difficult decison I really struggled with. BBS is both a good employer as well as a incredibly interesting place to be. The people, products and technologies are at the front of development in the banking sector in Norway, and sometimes also the Java community. I have learned so much, and the spirit and people of the eFaktura department have made going to work something I enjoyed every day.

So now I’m moving on and starting in Capgemini Norway in the position of technology leader for Java. There’s a lot going on, and the people I have met so far have been excellent. I am really looking forward to start as my head has been in two jobs for a little while now. It’ll be nice to have just one to focus on going forward. Exiting times. 🙂

See you in the new year! 🙂


Norwegian government open sources travel expense project

The norwegian department of renewal and administration has released an open source solution for managing travel expenses (english translation). This is an interesting event and I hope and think that it is a practice that will be followed in the future.

No doubt, I think it is a terrifying experience for most developers to have to publicly publish their code in such a high profile project. And surely it didn’t take long before someone was picking it apart on Twitter, but that’s just part of learning. Quality review is now free, focus on that. 🙂

What is important now is that this is handled as a living product where feedback is included and others get to contribute. And you will need an active core of developers, so the people that did develop it needs to be kept on payroll for a good while to actively improve the product. Over time more developers will hopefully contribute, but in the beginning the core group is extremely important.

I can’t wait to see more projects like this. It will increase reuse and savings in the public sector, and it will put the code out there for everyone to see and contribute. In the case of consultants beeing hired to develop software for the public sector, they can no longer say that a project was successful because it delivered according to contract. They will also need to deliver quality. The code and system will be out there for everyone to scruitinize. Let’s hope more and more projects get open sourced like this.