Snippets allow us to expand repetitive code without the need to type it entirely or rely on a menu of mostly irrelevant autocomplete options. They are quite useful and can dramatically increase the speed with which we produce functional prototypes. The longer we are busy with typing, the less time we have to develop our concepts. We start to think of which key we need to press next, instead of thinking in ideas, layering them on each other and focusing on the next step of the execution. It seems that snippets are still underutilized despite their availability in various editors.

Editors like Vim (with the snipmate plugin) and Sublime Text both support snippets, which fits nicely to their philosophy. We can define our snippets in a separate file and once it is saved, we can type things like ml20<Tab> and this could expand to "margin-left: 20px;", positioning the cursor after the semicolon. bdb1<Tab> could expand to "border-bottom: 1px;" and so on. We can create our specific language that the editor understands and pays attention to. By using such shorthands, we can quickly generate lots of code. Because this is easy, we need to take care not to include one that isn't strictly needed. And not to "jump" too fast if we want to retain what we did previously.

Getting rid of expanded snippets may not be as easy as the expansion itself. We need to select and delete the whole structure, which may require a combination of keys. The backspace key would be inefficient and slow since it works on individual characters, but not structures. It would have been nice if <Shift> + <Tab> could wipe out the last expansion, because what is easy to create must be equally easy to remove. We could use undo multiple times to arrive at the same result, but this isn't an exact opposite of <Tab>. Creating a preference for adding code over removing it can become visible over time.

Macros are another way to execute a specific command or a combination of commands by assigning them to a predefined key. But having many of them is often not practical as our keys are limited and they may start to interfere with the key bindings of our editor, which can lead to some unexpected results. What is good about snippets is that they unify all possible operations behind a single key. Their power is derived directly from our definition file and our ability to remember those definitions. Even if extending them is time well spent, we also need to think in advance of the cognitive burden we are imposing on ourselves. If we have to think long how to use something, it's probably better to simply move on, albeit in a slightly less efficient way.

The time required to define and maintain snippets can be a barrier for some developers, who simply need to get their job done. But we can think of our snippet file as an "investment" in the future, one that will allow us to work faster. Snippets can be personalized according to what we currently do. We can identify the most frequent repetitions in our code and define shorthands for them if they weren't available before. If we know what to anticipate, it helps to specify it too.

We can probably think of Emmet as a language for snippet execution. Expanding HTML markup based on input is easy and convenient. But if we like a particular structure, we can also include it in our snippets file. This way we'll only use <Tab> to get it and not write lengthy formulas every time or go back and forth to simply copy and paste what is available. A snippet file would allow us to accurately define cursor positions on each tab press, so we can navigate through the entire structure as we expand it. With Emmet we would need to manually position the cursor where we would like to continue with our markup.

In a sense, snippets are partially automating the way we write code, which may or may not be desired. For instance, a designer that has to use the programmer's way of doing things could feel creatively inhibited. The designer's work can't be automated and any attempt of doing so would create even more confusion and just convert the designer into another programmer. And it really shows when design was lost through the way towards a final solution. The designer needs to slow down in order to think through the implications of his/her decisions in order to generate feasible and relevant designs that people will be willing to use more frequently than once. Design is subject to so many changing forces and non-obvious things that automation can dehumanize it, which can happen one good intention at a time. It's really not of much help when the programmer insists of speeding up the designer with code. The best speedup doesn't come from code, but from the right decisions we take, preferably at the start of a new project. Code is just the manifestation of this decisions in written form. Programmers could help designers better by working more closely with them to create the creative tools they miss, not necessarily by speeding up their way of writing code. Meanwhile, designers can give some valuable ideas how to improve the development environments in which so many programmers spend the majority of their time. Exchange of experience is beneficial to both sides as long as they don't lose the focus on what they are trying to achieve.

Even if snippets have some downsides, they can still be useful in our daily work. You could try them out and see whether they work for you. If so, happy tabbing.