Archive for the ‘programming’ Category

Git is not (just) Source Control

Sunday, June 20th, 2010

After many discussions with a colleague about Git, I came to realize that Git is not merely a source control. With time it became a tool in my developer’s sandbox. To develop software effectively, I need (among other) an IDE or text editor, a prompt and countless libraries. I came to rely and trust these tools.

I used many other tools for version control but I saw them as infrastructure – mandatory in the grand scheme of things but not used to improve my productivity.

Git changed everything by allowing me to rethink the way commits and branches work.

  • By promoting small commits that do one thing but do it well, git forces me to split my task in even smaller chunks that can then be commited. This sometimes leads to architectural changes.
  • By making it possible to  reorder the commit history (git rebase -i origin), it pushes me to make each commit clean and atomic.
  • Git makes branching cheap and easy. Like you, I try to code each features in a separate branch. But unlike you, I am undisciplined and often forget. However if I start on a feature and realize it takes slightly longer than expected (and I’m talking about an hour max, not 3 days), I create a branch for that feature. It’s easy and it allows me to work in small, independent chunks. It also allows me to always be able to come back to a stable branch if I need to do a few quick fixes on another part of the project.

Git is not a mere tool – it changed the way I design and code.

Interesting Quote About Failure

Friday, May 21st, 2010

I saw this quote on 37signals’ blog and I thought it fit well with my latest post on failures.

“It’s important that nobody gets mad at you for screwing up. We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible.”

- Lee Unkrich, director of Toy Story 3, Wired magazine

If the goal is to screw up as fast as possible, you need an environment that allows you to do it safely.

Failure is an Option

Tuesday, May 18th, 2010

Failure is often a dreaded word. It need not be. Programming is an art where it’s very easy to fail and you can usually fail fast. Use it to your advantage. Learn to fail with style.

Give yourself the option to fail deliberately and safely. Many tools can help you:

  • Branches – Since I started using git, I often create a branch to play around with the code… then delete it and start again from scratch once I know where I need to go. This gives me the freedom to change configurations, disable features and modify code without tests. I even go as far as breaking existing features (sometimes they don’t even compile) if it makes me learn faster.
  • Prototypes – create a simple throw-away project to test your code.
  • Tracer bullets – whenever I need to connect a few modules together, I like to have a tracer bullet that will handle the normal path without any error handling. It gives me confidence that all the pieces fit together. It proves the chosen architecture works and yields the expected results.
  • Tests – if I want to know how a particular method/class reacts in a specific context, I will sometimes create a test to test my behavior. I might keep the test as-is or sometimes I throw it away and it becomes part of a larger test.
  • Scripting languages – ruby, python, groovy or whatever you fancy, these languages can often help you test an algorithm faster than in Java or C#.
  • Pen & Paper – low tech, but sometimes writing down your thoughts is the best way to go. If it doesn’t work on paper, chances it works on a computer is pretty slim.
  • Rubber duck – having an inanimate yellow friend near your computer that you can always talk to can never hurt :) .

A rubber duck

Code is cheap and fast to write… once you know the way. A few failures early on will help you get a success when it counts.

Why Katas Work

Monday, 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.