A colleague of mine thinks learning touch typing is a waste of time. He even suggests that it might be a disadvantage for a programmer to be able to type fast. While typing slowly, he reasons, one has time to reflect upon the work at hand. Well, I don’t share his point of view. I mean, should a cook not become skilled with his knives because slicing and chopping slowly gives more time to plan the next step? Of course not!
As a programmer, typing is what you do most, so you should spend time to become good at it. Touch typing is not only about rapid typing. It’s also about the freedom of your eyes. You can look at the screen and still be able to strike the right keys. That way you’ll discover typing errors more quickly.
Being able to look away and still type has another great advantage. When I get into “the zone”, my most productive state, I’d like to stay there as long as possible without interruption. If someone comes by I’m still able to continue my work thanks to touch typing. All I have to do is turn my face to the intruder and fake interest with nodding, humming and carefully placed responses like “mmm’right”, “mmm’kay” or “mmm’yes”. Try it, and I promise your productivity will skyrocket. 🙂
Learning touch typing has been well worth the investment for me. It took me approximately two months to become fluent, spending 20-60 minutes of practice every day. To my help I had Stamina, a free typing tutor software, which I gladly recommend.
You could, like me, create your own keyboard layout. I have based mine on a swedish version of Dvorak, with more convenient placement of special characters common to programming. I’m not sure I want to recommend creating your own layout though, at least not if you’re a Windows user. One thing I’ve had problems with is that certain IDEs have been shadowing parts of my layout, forcing me back to qwerty and my old-style typing. And, you’ll need your own layout installed, which is a problem if you’re using computers that belong to others.
Whether you decide to create your own layout or not, be sure to learn touch typing. You’ll be grateful you did.
Previous posts in the Tools of The Effective Developer series:
- Tools of The Effective Developer: Personal Logs
- Tools of The Effective Developer: Personal Planning
- Tools of The Effective Developer: Programming By Intention
- Tools of The Effective Developer: Customer View
- Tools of The Effective Developer: Fail Fast!
- Tools of The Effective Developer: Make It Work – First!
- Tools of The Effective Developer: Whetstones
- Tools of The Effective Developer: Rule of Three
I have a confession to make: I used to be addicted to debugging. Yes, it’s true. When I got hooked – damn you Delphi – I wasn’t able to see the dark side, the demonic side of the debugger. It lured me into the path of quick fixes. Heed my warning: debuggers are bad!
Fortunately I’m one of the lucky few who have been able to recover from this particularly addictive behavior. I’ve been clean – thank you jUnit – for almost 5 years now. And you can do it too, you can let go of the safety zone that these integrated debuggers provide, and break free just like I did.
The first thing to do is to realize that there is a better alternative: test-driven development. To get rid of a bug, the right thing to do is not to fire up your debugger, but to write a unit-test to reveal it. If necessary, keep writing tests and go deeper and deeper into your code. Eventually the tests will tell you what is wrong, and they’ll even point out a solution for you.
I know that using a debugger may seem like a faster way to find and extinguish a bug, but that is just an illusion. Here are the reasons:
- TDD improves the design. Being forced to think testability tends to divide your code into small manageable pieces. This will make your code a bad breeding ground for bugs.
- Tests remain useful for a long time. They become an addition to your testing harness, which helps protecting your code against future infestations. The work spent in a debugging session can never be reused.
- Unit-testing saves time, a lot! While this isn’t immediately obvious, the long term effects are huge. Think of it: all those debugging sessions can be run automatically at your command, whenever you want, how often you want, and in just a matter of seconds. All you have to do to achieve this is to let go of the debugger, and write relevant tests.
- Unit-testing gives you courage. There’s nothing like a good harness to make you feel invincible. I still remember the first time I felt the real power of unit-testing. I was working on a huge legacy application and had developed a new set of functionalities, using TDD for the very first time. Several months later I realized I had to do a major rewrite. The rewrite was risky business and took me a couple of days to complete. When finished, I ran the unit-tests which all came out green! I could be confident the program worked just as before the rewrite. And the best part: I drew the conclusion out of just five seconds of testing. Boy, I still get the goose bumps.
[PREACHING OFF]
Of course debuggers are useful tools. In certain situations they are even invaluable. For someone who’s new to the software they provide a great way of getting to know it. The problem is that a debugger makes you lazy. So be sure to get rid of it as soon as you identify a testing strategy.
Cheers!
I am a very busy man. I have a full time job as a project manager and software developer. In my spare time I am an freelance journalist, writing articles for a Swedish computer magazine. On top of that I am a caring father of two lovely children. Needless to say, spare time is scarce.
Both my job and my writing, as well as my wellbeing, require constant learning. The most convenient way for me to accomplish this is by reading. I love reading books. Tech-, popular science and fiction books – I devour them all.
The only problem is when to do it. I am always busy, either with work or with my family. But the optimizer in me has found a solution: I read while in the toilet. Tech-books are especially well suited for toilet-reading. They are usually well structured and have relatively short chapters. I tend to keep at least a couple of them lying within range.
Of course, I sometimes take unnecessary long time doing my needs, and sometimes my wife complains about it. But you know what they’re saying: a man’s gotta do what a man’s gotta do.
I’m a great believer in automating time consuming tasks. Since deploying my rails application (the Forlorn Hope movie site I told you about in my last post) has become increasingly painful I decided to automate it. Today I succeeded. It is not a simple task for someone who’s knowledge in Unix server administration is limited, but I made it! I’m finally there.
The basic ingredient is Capistrano, a rails/rake extension designed to automate the deployment of rails applications (although not restricted to that). I may do a write up some day but for now I will just enjoy my newly won ease of deployment. You know: change a little bit here – DEPLOY! – change a little bit there – DEPLOY! Wah, I love it!
If you don’t want to wait for my write up there are plenty of information on the Internet to get you started. Be prepared for extensive tweaking though.
Installing a rails application at TextDrive
Lighttpd the painless way
You need to install the subversion client
How to deploy your first rails application using Capistrano in Windows
Shovel – Rails deployment with Lighttpd