It Doesn't Matter How Fast You Write Code
What matters is the outcome
Years ago I was in a small project when a colleague showed me a different way to write HTML. It was an extension for text editors that allowed me to write a simplified markup language. If I pressed the return key after I wrote it, the extension generated the HTML markup.
The tool had the promise to increase my speed and, by consequence, my productivity.
Tools like that can increase your speed, but that doesn't mean they increase your productivity. To understand why, you need to look at the difference between speed and velocity.
In physics, speed is "how fast you go," and velocity is "how far you go." In other words, velocity is the movement with a significant focus on the destination; speed is only the movement. For more details, see this video.
If you go faster that doesn't mean you'll go further. If you spend the effort to increase your speed, you'll probably miss the improvements that can increase your velocity. That can halt progress.
If you want to improve something, at least make sure it's the right thing.
If you type faster, you might increase your productivity in companies where developers are considered Code Monkeys. However, if your goal is to go far, productivity should be measured by means of velocity, not speed.
What does that mean?
A good example is testing. One of the many purposes of tests is to reduce the feedback cycle of development so that you don't have to spend time going back to code you've already written. Coding faster without tests gives you the perception of productivity because it increases your speed, but it reduces your velocity because you have to fix regressions over and over again.
Another example is incremental programming. If you code faster but have nothing to show, then, by all means, it's the same as having done nothing. You'll never know earlier if you're going in the right direction. If you split your tasks incrementally, you always have something to show and get feedback.
I've written before on how the most valuable resource of a developer is the brain, not the fingers. Tools like that extension fail to increase real productivity and can even have the opposite effect. The perception things are going faster prevent you from noticing that you're not moving anywhere.
There’s a difference between speed and velocity. The latter is what gives you progress.
Command line tools share the same principles.
You probably have some personal Git Aliases for many commands you repeat every day in your work. It's a common practice to have things like git ca for git commit amend, git cp for git cherry pick, and others. Those aliases help you to type the commands faster. However, they also hide the underlying implementation.
To master Git, or any other command line tool, you need to understand how they work and what they do. The first step is to memorize them so that they become part of your common vocabulary. An efficient way to memorize commands is to use Blocked Practice, that means to leverage your brain's Muscle Memory and prefer to type the extended version of every command you use. This way, you won't forget how each command works given the massive amount of exercise.
If you’re always working alone and have built a strong Muscle Memory with a given command, an alias might increase your productivity to some extent. However, not only if you’re learning Git, but also if you do Pair Programming, it’s counterproductive to use aliases because they hide information.
I’ve been using Git for almost a decade, and I always prefer to type the extended version of its commands, even when working alone.
The use of aliases prevents your brain from exercising the Muscle Memory for the real command.
Developers tend to create aliases and abbreviations for everything, building layers after layers of indirection to build speed at the cost of velocity.
The way beginners code in JavaScript is an excellent example of speed versus velocity. Just because you don't have to "write a lot of code," that doesn't mean you're productive.
The problem with speed is the same for all types of shortcuts, not just the ones you type. Shortcuts are useful as long as you understand them, don't let them leak, and don't let them hide information.
On that day, when my colleague presented to me this new way of writing HTML, I explained the differences between speed and velocity.
I explained it doesn't matter how fast you type and how productive you believe you are.
What matters is how much you move forward.
What matters is the outcome, not the output.
See also an interesting discussion on the question: "So you do not use any templates to create code (or snippets)?"
