I planned on continuing my training sessions while I was on vacation. However it seems that I am even more tired after a day in the sun than I am after a day at the office. Go figure.
Anyway I decided to put the training on hold until I come back. A guy has to take a break from time to time. And it gives me more time to read and think about my objectives for the next year. That’s what I’m going to do for the next two weeks.
I’ll continue to do katas and small projects when I come back.
As I wrote a week ago, I trained touch-typing this week. My objective was to attain 85 wpm. Here’s a recap of my week:
Monday : I decided to use Typeracer as my baseline. It’s an online game that allows you to race others. The fastest typist wins. I had not played in 6 months or so – and it showed. My score for the last ten races dropped a bit. This was not a good start. Result after the day : 74 wpm
Tuestday : I did some drills on goodtyping.com to get back to speed. It must have helped because I raised my speed to 78 wpm.
Wednesday : mostly played Typeracer. I managed to cut down on typing errors and I’m up to 81 wpm.
Thursday : I tried to practice at night instead of during lunch time. Without much success – 80 wpm. My fingers were not obeying me. I did a few drills on goodtyping.com to increase accuracy.
Friday : Success! I managed to consistently type over 80 wpm today by concentrating on typing slower but with less mistakes. I managed an average of 87 wpm on my last 10 races.
The week is over and I achieved my objective of 85 wpm. I did this mostly by reducing mistakes – they can get really slow you down.
Thanks to my colleagues who followed in my track and helped me focus on this challenge.
I believe in software craftsmanship and in training to become better.
That’s why when I was challenged at work to take a few hours each week to train, I thought “What a great opportunity!”.
Well that’s what I should have thought. Instead I said: “But what about the project? The deadline? The world is going to end!”
Then I realized how lucky I was to work at Pyxis. I asked the Product Owner and it wasn’t such a big issue.
Lesson #1: Ask and thou shall receive
For my first training session, I decided to do the some katas in ruby as it has become my language of choice for pet projects.
Part 1 – Primes
I started my first session with the Prime Number kata. I like this kata since it is really simple, can easily be done in less than 30 minutes (closer to 10 once you’ve done it a few times) and I learned a few useful tricks in ruby by watching this kata permormed by Uncle Bob on Katacast.
I plan on doing the Prime Number kata every week as a warm up.
Part 2 – Bloom filters
Afterwards I tried kata #5 from http://codekata.pragprog.com/2007/01/kata_five_bloom.html – implementing a Bloom Filter. It’s an algorithm that probabilistically determine if an element is part of a set. It works like this : if the element is in the set, it will always return true. However if the element is not in the set, the bloom filter might still return true depending on some probabilistic stuff.
Here are my highlights of the session:
- I learned a new algorithm, it’s purpose and a few use cases
- I performed everything in pure TDD
- Continued to learn new keyboard shortcuts in Rubymine (I try never to use the mouse in katas. If there is a keyboard shortcut I forgot, I look it up and make a point on using it)
- I managed to take some time to train!
The only downside I can think about is that I spent a little while trying to configure ruby 1.9.2, rspec and the latest beta of Rubymine 2.5 before reverting to ruby 1.8.7.
As for improvements, I see lots of ways to improve the Bloom Filter katas, especially when it comes to my tests. I’ll give it another try next time.
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.
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.
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.
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
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?