You type too much. Whether it’s in the command line, your editor, repeating the same code patterns, or whatever else it all comes down to one thing: you type too much, and I’m here to help fix that.
The irony here is that this is a long article in which I most certainly type too much. This is far more an overview article than anything, and there will be followups detailing the covered sections at a later date.
Noted that I’ll try and include books I’ve read on some of the below that I’ve found handy. Know of another? Leave a comment!
Learn your Shell
Chances are high you’ve been repeating a lot of commands on your shell, especially around git and history based items. After a while all of those characters can add up, time to cut them down to size.
Noted that I mentioned some of this in an earlier article: http://baweaver.dev/blog/2013/09/29/getting-cozy-with-the-command-line/
If you notice yourself typing something more than once, or typing a string of commands you tend to forget, it’s time to break out some shell scripting and knock things down to size.
If you haven’t checked it out yet, ZSH is loaded with aliases and extra power from the start. I won’t cover the list of features, but the ones we should be concerned with are (and some exist in BASH):
- Tab Completion
(note: Oh-My-ZSH has a lot of this built in: https://github.com/robbyrussell/oh-my-zsh)
How often do you find yourself typing in
git add or
git commit -m or other items? You can alias those into a few characters, saving a lot of typing:
1 2 3 4
Now what’s the difference here between that and Bash? ZSH supports global aliases which can be used anywhere in a command. Let’s say you want to keep a log of a statement:
Functions, much like any other language, can be used to combine actions. Sometimes a quick function in your shell is all you need.
How about getting your current branch name for a commit message?
1 2 3 4 5 6 7 8 9 10 11
I tend to use this a lot for grep, less, and other common shell functions in my workflow. It’s really handy when it’s some heinous AWK or SED line I don’t want to remember.
While this works in Bash with some extensions, it comes built into ZSH. Even more comes up when you have Oh-My-ZSH which uses Compleat: https://github.com/mbrubeck/compleat
If you’re like me and you prefix your git branches with tags, you can autocomplete against that if you happen to misplace a branch.
Learn your Editor
Your editor has features designed to save time as well. While autocompletion comes to mind, I personally find it tedious and not nearly as powerful as other features such as snippets and macros.
The first considerations in sublime should be those mentioned on the front page, such as column selection and multi-select for words. It’s worth it to read the documentation there as there are several features that will be immediately usable.
There’s a sublime plugin for pretty well everything, including that documentation you hate to write by hand and can never remember the syntax for.
Sublime comes built with the concept of snippets, letting you define blocks of code with interpolatable tags:
1 2 3
These can be bound to language specific contexts, preventing overlaps for potentially the same names (jasmine vs rspec snippets anyone?)
These are going to look very familiar if you’ve been using vim, at least in terms of key commands.
A macro is a series of actions that can be replayed at a later time, even bound to a key combination.
Catch yourself correcting 4 space indentation to 2 space? You can macro that!
An evil left-bracer got a hold of your files? You can macro that!
Someone is writing Java on your team and you want to get rid of it for Scala? You can macro that one too, but a bit more hackery and a priest to contain the evil during the exorcism will be required.
Much of the same general features in Sublime are available in Vim with some extension, including substantially more powerful macro and snippets features. Sublime just happens to come pre-baked with simpler sane defaults.
Vim can use the command system to execute whatever you want from the shell, learning to use this will be of extreme benefit. You can even go as far as having your own scripts directory for generating more code on the fly.
You remember how sublime snippets can interpolate values for you? Ultisnips takes it a step further by taking those interpolated values and using them to generate more.
Why is this useful? Think initializers and documentation skeletons. Learn a bit of Python and you can be off with substantially more dynamic snippets.
What about x IDE?
IDEs are designed to cater to a wide base, and more times than not I find that assumption to make it very annoying to work with. Instead, editors like Vim and Emacs allow me to build things from the ground up, catered specifically to my style of programming.
It should come as little surprise that you tend to remember shortcuts that you yourself make as opposed to memorizing a list of commands and keyboard shortcuts.
Then why do I use Sublime on occasion you may ask? Sublime is far less likely to cause someone to incite physical violence against my person when pair programming than a modded-out instance of Vim with remapped keys everywhere.
That, and Sublime is quite frankly a much better editor for people starting out.
My religious preferences (vim) prevent me from giving credence to such an eVil editor :P. On a serious note, never saw much of a reason to bother with it as I already knew Vim from SysAdmin work.
Learn to recognize unabstractable duplication
There are a few frameworks out there that have a concept of generators. Two of them are Yeoman for NodeJS and Generators for Rails.
Creating generators that are catered to the style of your team can greatly reduce the time and mistakes made when implementing a new section of code. Even if that code can only accurately generate up to 70% of your shippable code, that’s 70% you know works and has passed style inspections and the like.
Yeoman, it seems, has a bit of a sense of humor in that they’ve gone and made a generator-generator to help you make more generators. A bit meta, but quite useful in getting started.
Yeomen generators come with options for making prompts much like a wizard, and the nice thing is that they remember your last responses as the new default options.
Say you like a certain generator but need to get more done, just compose it with another generator to get them to run in tandem.
You could even tie them into your editor using custom made adapters. As long as you respond to IO properly, Yeoman can take care of the rest for you.
A lot of people I know in the Rails world complain about the viability of scaffolded code, saying it comes no where close to what they intended. Well handily enough you can customize every step of the scaffold process, including the style of models, controllers, and views they generate.
Say you just want a simple searchable and sortable bootstrap table with CRUD operations, maybe make that an Angular or React view? You can do that with generators with some customization. You can even generate the RSpec and Jasmine for it while you’re at it.
Don’t underestimate Rails Generators because they’re abused by newer coders. Thumbing your nose at it is a serious mistake.
Learn to let your code speak for itself
Of course you could make generators for all of your code, define the perfect styles and agree on everything, but what if something else could generate it already? Seems like a waste to ignore.
Fortunately there’s such a concept of generating services code for RESTful APIs, present in a number of frameworks:
In most of these you can treat your API definitions as generators for your client service code. Imagine not having to write services in Angular or other frontend frameworks.
Now if you’re clever, you could even tie this into an inline-api tool like ApiPie to create things in line with your actual API methods giving you both documentation and workable client code at the same time.
The main thing in reducing typing is to never be content running a long string of tasks. Always be looking for areas that can be improved, reduced, or eliminated altogether. Most of this same mentality is already applied to our code, so why not the process leading up to and around our code as well?