While there are few who would disagree with the statement, there are many programmers who are extremely poor typists. Why does it matter in an age of IDEs that complete code? The following are some consequences of bad typists as programmers. As a side note... for the duration of this article, please substitute keyboard for "generic mode of input". The point of the article is mastery for said mode of input, which for 99% of developers is a keyboard. The point is still the same, no matter how you get the code into the computer, you need to be an expert in using it.
1. Bad typists often take confusing shortcuts when naming variables
Most programmers are lazy by nature. For many of us, it's how we became interested in programming in the first place. However, when you add poor typing skills to a person who is already lazy, you end up with shortcuts that do not lend themselves to readability. The result is short variables and method names that are not descriptive of their purpose. The code may work, but it takes much longer for someone else to change it and sometimes the original programmer may not understand their own work.
2. Bad typists avoid refactoring
Sure, the most common refactoring can be done by the IDE, but truly reorganizing the code is much more laborious if one can't accomplish it quickly. Refactoring is one of the most important things we do. Most of the time, the first pass at solving a problem either doesn't work or works but is very poorly written. Additionally there are times we make it all the way through a piece of functionality only to find that the requirement has changed and the original approach resulted in code that is not optimal or just plain doesn't work. Refactoring is often a typing intensive task making the barrier of entry to a bad typist even higher.
3. Bad typists avoid deleting code
You've seen it before. Commented code everywhere. While I sometimes check in commented code because of a variety of reasons, I can't get over the feeling that I should take a few lashes for doing something so terrible. I hate commented code. I hate it like I hate System.out.println for logging statements. I have very little tolerance for commented code for a number of reasons too lengthy to go into here. To put it simply, if it's in a comment and it is not prose, it had better be a mistake or have a very good reason for being there. If you're going to comment it out, you might as well delete it. Source control keeps track of history, so you aren't losing anything. However, many poor typists comment code rather than deleting it because they simply don't want to go through the effort of re-typing it.
4. Bad typists spend more time typing and less time thinking
The answer is that a good typist spends more time thinking and less time going through the exercise of getting their code out of their head. Lets face it, if there was a faster way to get a thought from your brain to your IDE, you should use that. Until then, typing is how we do it. The faster you go through the mechanical process of putting it down the more time you have to actually think about what you are doing and if it is a good way to solve the problem you are attacking.
5. Bad typists write incoherent code
That is a pretty bold statement that I am making with little to no supporting evidence. However, I know that when I have to look down for a key I lose focus on what I was doing. Normally it's easy to regain because it doesn't take very long to find it, however, losing focus can mean losing flow if you have to do it too often. Coherent code comes from a single stream of thought. Thoughts should flow freely and not be interrupted by the fact that you need to know where a ? is. The less a programmer thinks about where the keys are, the less chance they have of breaking the flow of thought going into the code.
What's the answer?
1. Practice, practice, practice. Typing exercises help, as long as you do more than just letters(pipes, tildes, semi-colons and so on). Practicing with only the most common letters is better than nothing, but a programmer needs to be able to type quickly using the punctuations required by programming languages. If you have to look down on your keyboard for a semi-colon and you code in a language like Java, you will be looking down on almost every single line, slowing you down and interrupting your focus.
2. Get familiar with *A* keyboard. Changing keyboards all the time is obviously detrimental to your ability to type quickly. The constant state of flux means you never learn anything really well. To alleviate this problem I recently purchased a TypeMatrix keyboard because it's small, it fits in my laptop bag, and it has enhancements to make me faster. The fact that it's small enough to fit in my laptop bag means I don't have to use the laptop keyboard when I am away from home, thereby giving my fingers a comfortable environment all the time. This is not meant to be an endorsement of my keyboard... the jury is still out on if it will have the promised benefits, but over the first few days it is definitely making a case.
Think about your keyboard like a Marine thinks about his rifle. So I close with my rendition of the "Rifleman's Creed", altered to fit the topic.
This is my keyboard. There are many like it, but this one is mine. My keyboard is my code. I must master it as I master my code. My keyboard, without me, can write no code. Without my keyboard, I can write no code.
My keyboard is my livelihood, thus I will learn it as a brother. I will learn its weaknesses, its strengths, its parts, its accessories, and its features.
In order to be efficient in my tasks I must do these things. I will...
No comments:
Post a Comment