Rubberducking

Code Reviews – A Positive Experience at Last

January 22nd, 2010

In the past I had terrible experience with code reviews. Proposed changes never got integrated. The same people were always doing the code review. Some reviews were almost useless – very little comments except for “this getter is not documented and that’s our coding standard”.

That changed recently and I now appreciate being on both sides of code reviews. Everyone participates and the reviews I received improved my code. Hopefully the reviews I gave did the same. Since we started I think the quality of our application is higher.

Having your code reviewed has great advantages:

It forces more rigor. Comments help to clean up and be more consistent.
It helps to make code clearer. If code is not understood by your peer, there’s a good chance you won’t be able to understand it in a month.
Reviews often simplify code. Your colleagues might have code to solve the same problem or they may know a better way.

That’s only one side of the story though. Reviewing code offers other perks:

It spreads knowledge and helps to break silos.
The reviewer sees other designs. Some of your colleague’s ideas might be worth stealing.
It helps to get better and faster at reading code and understanding algorithms.

Maybe it’s just me, but I believe code reviews make me achieve higher coding standards. What I would like to improve in my team is to get a shorter feedback loop. I try to commit early to get initial comments on my feature. Unfortunately everyone is busy and code review is not always the priority of the day so I often have time to finish the feature before it gets reviewed. Nobody’s perfect – I’m the first to be guilty of prioritizing the feature I’m working on over a review. I’m committed to change my priority from now on.

What should be reviewed to make your application better? Functionality. Compliance to requirements. Code. Naming conventions. Tests. Design. Clarity. Documentation. Usability. Performance. Everything that matters to your team.

Perfection lies in details. Code reviews is one way to make your app shine.

Posted in code, practice | 5 Comments »

links for 2010-01-12

January 13th, 2010

Posted in bookmarks | No Comments »

New Home

January 8th, 2010

Rubberducking has moved to a new home on http://www.mathieuberube.net/blog

Everything has (hopefully) been moved from Blogger to WordPress. Tell me if you find any problems.

Posted in Uncategorized | No Comments »

Make Amends with Git

December 30th, 2009

I’ve always been a fan of small, concise commits. I strive to make my commits as small and concise as possible.

However I often fail… Very often I commit and… discover that I yet again forgot to fix a typo. Or remove a blank line. Nothing major. But it’s pretty annoying to have every other commit log reading ‘fixed typo’ or ‘formatted code’.

With Git, I don’t have this problem anymore.

If I want to add some changes to the last commit, I simply type:

git add somefile
git commit ––amend
Tada! I just modified my last commit to include new changes.

The other option I like to use from time to time is the rebase interactive mode. I use it to merge various commits into one. It has more powerful uses (like removing commits entirely) but I never used these (yet).
git rebase -i origin

Of course you have to use these commits before pushing anything to a remote repository.

With these these two commands, I can keep my commit log a little bit cleaner.

Posted in git | No Comments »

Why Katas Work

December 28th, 2009

Musicians, singers and athletes have something in common – they do a lot of practice to become the best. They may have a show or a competition from time to time, but they practice every day.

Martial arts practitioners do katas over and over. At some point it becomes a form of art.

Can the same be done with code? Can you practice to code a certain piece of software over and over until it becomes art? Uncle Bob certainly thinks so. I started doing some katas a few months ago but a question was still nagging me : do they really help me become a better programmer? Does practice matter?

According to The Talent Code, the answer is probably yes.

The book explains how to harness your talent, how to become an expert in your field. And it seems that all world experts, no matter their field of expertise, have spent a lot of time (10 000 hours) practicing. Not just any kind of practice – you can’t just play around and hope you’ll learn something. There is a concept of ‘deep practice’.

There are three parts to deep practicing:

Chunk things up – slow things down, do a simple part of the whole
Repeat – a lot
Learn to feel what you are doing

I think that’s what I’ve been unconsciously doing with katas. I wrote the same application every time. But every time I was improving, basing the next iteration on past experience. I was using more keyboard shortcuts, less code, better idioms to express myself. I was learning from my mistakes and becoming more efficient.

I believe that katas help me to ‘deep practice’. It forces me to reflect on what I’ve done and learn from my mistakes. In the end I believe it helps me to improve.

That’s good enough for me to keep doing it.

Posted in practice, programming | 1 Comment »

Switching to the Penguin

December 19th, 2009

Finally it’s done.

After months of talking about it, I finally dropped Windows and installed Ubuntu.

I decided to switch because I was tired of reinstalling Windows every year or so otherwise my machine was slowing to a crawl. Plus I mostly use open source software anyway. And I kept installing utilities to help me have a real prompt (I can’t live without grep anymore…).

My first impression is that apt-get makes it a breeze to install a new machine from scratch. No need to download all the apps separately like I did on Windows, pretty much everything is one apt-get away.

A very positive experience so far!

Posted in linux | No Comments »

Git Part 2 – Share Code with (a few) friends

November 28th, 2009

In my current project we shared code among a few team members without impacting the others using Git. Since it happened twice and I already forgot it once, I put it here as a personal reminder. Hopefully it will help you too.

Imagine you’re working on a feature and a teammate wants to use your code. But you’re not finished, your code might break the build or some other functionality is broken. You have a few choices. You can send a patch. You can accept that the build is going to be broken. Or you can use Git and create a temporary branch for the sub-team to work on.

Setting up

Let’s say you need to work on a new feature. First you create your branch:git checkout -b myfeautre

The feature takes longer than expected. And you need help. But your changes will break the application and you don’t want to impact every one. So you push your branch back to origin:
git push origin myfeature

Get work done (with some help)

Those who want to help you can create their own local branch.
git fetch git branch myfeature origin/myfeature

I suggest you delete your own local branch and create another one as above. Your new branch will be linked to origin/myfeature so push/pull will work as usual. If you know another way to do this without deleting your branch, please tell me.

To sent your changes back to origin/myfeature, simply do

git push origin myfeature

Now everyone involved in the feature can commit as they wish.

Cleaning up

When you’re ready to merge back to master:
git checkout master git merge myfeature

Then delete your old branches once everything is working:
git branch -d myfeature # deletes your local branch git push origin :myfeature # deletes the remote branch

Gotcha:
If you push using git push, it will push every thing from every branches, including master. Make sure all your branches are in a stable state when pushing. Otherwise you can push a single branch:
git push origin myfeature

I you feel I missed anything, don’t hesitate to tell me.

Posted in code, git | No Comments »

Discovering git – How to have fun with a SCM (again)

November 26th, 2009

I started using git about three months ago. I just love it. I had lost touch with the joy of using a VCS from the prompt. I was getting pretty used to CVS at the time. Then I entered the dark era of Clearcase. Most features were available from Windows Explorer so I got used to that. And I continued after for about a year using SVN with Tortoise. I could have gone back to my beloved prompt but I had lost my way.

Then came Git. And a host of neat little features that made me want to switch right away.

The first thing I loved about Git : you don’t have any .svn folders in your project tree. Only a single .git folder at the root. Which means that you can use any tool you want to move and rename your classes and git will figure it out somehow. With SVN you had to be more careful – it happened in two of my project when someone (once it was me) thought it was a good idea to move a folder without a tool blessed by the SVN Gods. Bad idea – since the .svn folder is also moved, SVN still believes that it is committing files to the old directory.

With Git that’s a thing of the past. It’s a small thing but only this made me want to switch.

Then on my first Git project we merged two completely different repositories preserving the history of all the files. Nice.

And it’s very easy to get started. No need to setup a remote repository. You can have most of the power of git with a local repo. ‘git init’ and you’re ready to start. I now use it with all my projects, not matter how small.

And from then on, Git became favorite source control.

What are you waiting for? Try it! You won’t regret it!

Posted in git | No Comments »

Inspiration

November 25th, 2009

If you read yesterday’s post and wonder where you can find motivation to start to practice, look at this. It’s a screencast of Uncle Bob doing a Code Kata. A simple exercise, but if you look at the screencast you can guess he practices more than a few times.

I was tired tonight, but that’s going to keep me going

Posted in code, practice | No Comments »

10000 hours

November 24th, 2009

There is no secret to developing a new skill.

Practice. Again. And again.

Looks like you need to practice a skill for 10000 hours before you can master it. That’s around 10 years of deliberate practice. This applies to Olympic athletes, musicians, and… programmers.

That’s one of the idea behind Malcolm Gladwell’s Outliers.
The idea was also explored in Pragmatic Thinking and Learning.
Also see Peter Norvig’s ‘Teach Yourself Programming in 10 Years‘

So what have you practiced lately?

Posted in practice | No Comments »