It’s safe to say that programming, and everything around it, evolved tremendously since the Internet’s beginnings. If you’ve ever created a Frontpage website or battled with Dreamweaver and Flash applications you know we’ve traveled a long way to get where we are now, and all along this way great strides were made to improve how we work. We’ve got better languages, better tools around them, better integration, and interoperability. We tried to standardise things and rethink how we worked in the spirit of making it progressively easier to implement ideas.

And yet, things also didn’t change that much did they? When you look at what constitutes a day of work, for a lot of programmers it still amounts to looking at lines of code on a plain background, looking at a terminal window, typing the same commands again and again. Why did that not improve as drastically as everything else? Or did it improve and instead we’ve grown so accustomed to learning just enough to be functional that we’ve forgotten to seek improvement? How many people use Git daily and know at best three or four commands?

Or did it improve and instead we’ve grown so accustomed to learning just enough to be functional that we’ve forgotten to seek improvement?

Being a fast programmer isn’t all about architecture and reasoning and solving problems. While it accounts for a good chunk of it, once you remove the “coding” part from “coding” what makes a programmer faster than another? The answer is the ability to reduce friction — everyday micro-slowdowns in and around every task — that we sometimes let fester as a part of our workflows.

So what can you do to get faster and remove these slowdowns?

Let’s review some great starting points to help us be more productive.

Hocus Focus

The first thing we need to eliminate is distraction. Imagine you have an issue to work on, you know precisely how you’re going to implement it, and all that is left is the dirty work. The first thing you should try is to get some additional focus. The internet is the Great Bastion of distraction: its only purpose is to grab your attention and hog parts of your brain capacity. So, a great first step is to kill everything else but the task at hand: quit Slack, quit your email, put your phone on silent, and maybe put on some nice ambient music.

By removing external distractions around you, you allow your brain to focus entirely on the task at hand instead of letting it multitask and think about notifications and other tasks. This focus will make it that much easier to get in the zone and achieve great strides in productivity. Think about all the time spent alt-tabbing to check a notification that you didn’t even need to care about in the first place; think about all the brain time occupied at thinking on multiple levels. This is the first chunk of slowdown you need to eliminate. So, first step: create some head space around you to comfortably work in. If you’re working from home, try working from a different place, as long as it also helps reduce the amount of distractions.

A great way to get started quickly with Focus Time is to create an Automator quick action workflow that quits all annoying applications. Automator is an app that comes with Mac and allow you to automate all kinds of tasks, and you can even use Javascript in it! You can easily create Quick Actions which are actions that can be run from the menu bar in any application. To create one launch Automator, pick New Document, and in the type of document pick Quick Action. You can then add various automations to your workflow, such as quitting applications:

Then from any application you can go to The App → Services → Your Quick Action and it will run.

Once you’re used to focusing regularly, you need to remember that with great focus comes great responsibility — another aspect people often overlook is to take frequent small breaks. Those help clean your palate between two tasks and prepare your mind to focus more intensively. You cannot have one without the other. If you want to dedicate yourself to one task, you also need to learn to let go of others.

Terminal Velocity

Once you’ve achieved some calm, let’s next look at the terminal. The terminal should be every programmer’s best friend, and if you’ve always put off learning to use it you’re definitely preventing yourself from reaching full speed (even though there’s some amazing GUI tools out there).

Aliases

The most important thing you need to learn is to create and use aliases. For this you need to think about all the commands you type in the day and think of which ones you’re tired of typing. The key is to realize an alias doesn’t have to be a full command, an alias can be partial, e.g. an alias like  alias gco=git checkout can be created and then you can use gco my-branch.

You can put all your aliases in any file loaded on login (.zshrc, .profile, .bash_profile, etc.). Don’t be afraid to create a lot of them even if you don’t memorize them. At any time, you can look for a particular alias by doing alias | grep checkout, for example. Calling alias alone will list all registered aliases, and grep will allow you to easily find whatever command you’re looking for.

If you’re not creative with aliases then install some! You can find some great aliases on the web and if you’re using zsh with Oh my Zsh or the excellent zplug then you can install plugins which will come with loads of aliases ready to use, so I’d recommend starting there.

History

Another thing I see very few people use is your history. Did you know you can lookup any command you’ve typed and just redo that command? Does that seem like magic? Because it is and you should absolutely know about it. You can start using it very simply: press Ctrl + r in your terminal, start typing your command, and press Enter! That’s it! This one simple trick will save you hours and hours of typing commands — doctors hate me.

Now, whenever you need to type something, and I mean absolutely anything that is more than 5 characters, I want you hitting that History like a drum set. Checking out a branch? You’ve probably already checked it out in the past. Running some scripts? Probably already done it at least once too. Whatever you’re typing, you’ve probably already typed it because we type dozens of the same commands again and again every day. So no more. Stop losing time typing the same things, a quick Ctrl + r, type three letters, enter and bam. You’re not a code monkey. This isn’t where your value is so stop losing so much time on typing commands.

If you feel the default UX of Ctrl + r is average, then you can install fzf which is an amazing tool bringing fuzzy search to most autocompletions. This will allow you to lookup commands by any string of characters in them and it includes even more advanced stuff.

Directories and moving around

Another huge source of friction is moving around on your computer. Here again there are some great tricks to put into practice. But the best tip I can give you is to install z and call it a day. It’s a terminal tool that will remember every folder you’ve been in and allow you to do z foo, for example, and immediately go to the most visited folder containing “foo” in its path. It’s dead simple but with it you’ll never have to type a path again, just z projectA or z Sites or z myUsers. As long as you’ve been in that folder once, it’ll find it.

Besides that, the best trick is to create some great aliases to move around, such as the ones that come with Oh My Zsh, e.g. alias ....=cd ../../../../. I also notice a lot of people don’t know about cd - which lets you go back to the previous directory you were in which is very, very useful if you want do one quick action in another folder and go back (and it also works for Git branches!). There is also a great plugin called jump, again in Oh My Zsh, which lets you manually bookmark folders and go back to them.

Git

I’ve mentioned before that most people know very few Git commands. This isn’t necessarily a bad thing, more a reflection of the fact that you can accomplish so much with so few commands. You can have been in the industry for years and still get by with just checkout , commit, and push. So there again, use aliases. Please don’t type git checkout my-super-long-branch ten times a day, even if you use Tab to autocomplete it.

If your project uses Git flow, don’t hesitate to install aliases for this and the great gitflow-avh binary which will turn long commands you type like git flow feature start my-feature into the much more condensed gflfs my-feature. That alias may seem cryptic but it’s purely initials (Git Flow Feature Start) so once you know one alias you know them all.

Editorments

The terminal is of course only half the story. Most of the time your work is done in an editor or IDE. Most of those tools have one goal and one goal only: make you as productive as you can be when writing code. Yet very often, like for Git, people stop once they reach “minimal productivity” and never really bother to check all the features their editor or IDE have.

The first thing people ignore, and it’s very akin to aliases, is keyboard shortcuts. It’s something people aren’t curious about, they learn four or five and spend years using just those, never bothering to learn shortcuts for actions they do ten times a day such as run a test, go to a class/file/method, or refactoring something. So my advice here is to take 10 minutes from time to time and learn one or two shortcuts. our future self will thank you. It’ll feel hard at first because it’s all pure memorization, but I guarantee you someone who truly utilizes their editor and their shortcuts can be almost as fast as someone going full speed in Vim.

Extensions are another great place to look since most editors and IDEs have ones that provide code templates, snippets, and other things you can expand into boilerplate code. For example, you can find React components or PHP classes skeletons to fill in. Also use autocomplete as much as you can — good editors will automatically import classes/modules and such when autocompleting them. How many times have you typed import React from "react" in the past week? If your answer is any number above one, I recommend you take a look at how to import it automatically. Emmet is another great multi-platform extension with a big set of snippets ready to use and it even works in JSX to allow you to easily wrap elements or generate huge chunks of HTML.

IDEs tend to be more feature-full than editors, so look into special productivity features in those as well. The whole IntellijIDEA suite has a very helpful Help → Productivity Guide listing all the tools the IDE gives you, what they’re for, and how many times you’ve used them (or not). This is available in PHPStorm, WebStorm, PyCharm, and others so definitely check what your editor can do for you because chances are you’re severely underutilizing it.

One last tip that has saved me countless hours in various situations: learn to use multiple cursors! They’re an incredible way to repeatedly write multiple lines of code that only diverge slightly. Imagine you have a value objects with various setters. Instead of writing the code to set the values manually, use multiple cursors. Place one cursor at each setter method, copy it, and paste the multiple lines somewhere else where you can write them all in one go, no matter whether your object has 5, 10, or 50 setters. This is one of the features I use the most every day and once you start using it you’ll start seeing how often you need to write multiple lines in a redundant way.

Code Speed: You!

Once you’ve tamed your tools a bit better and have achieved greater idea to implementation speed, don’t forget to look at friction in and around your code. This can be a lot of things.

Code Formatters

The first one I want to talk about, and one I’m very passionate about, is to use code formatters. If you’ve ever commented “The indentation looks wrong here” or “There’s an extra comma on this line” on a pull request, you are absolutely wasting hours a year doing menial work that tools can now do better than you.

I’m not going to dive too much into which formatters are best since every language has their own top dogs, but I will absolutely recommend Prettier for many languages, even PHP. In combination with something like PHP CS Fixer it gets the job done. If your tool only warns you about incorrect code style, you’re not using it right. Use tools that can reformat the code for you and FORGET IT! Stop worrying about code styles; instead use one for everything and LET IT GO. This is legitimately a very deep sink that has caused billions of lines of angry ranting to be written, so let it go once and for all and you will quickly see how much time in your day you spent mindlessly moving bits of code around.

The trick and the core of this advice is that it has to run on save for it to be truly different. If it only runs on commit, chances are you won’t drop the habit of formatting code; you’ll start to write some lines and automatically indent and space things around properly because that’s how you’ve always done it. But don’t. Make your formatter format on save, write disgusting code all in one line, press save, boom, clean code. You’ve just saved 30s spent uselessly arranging strings of characters in a neat way.

Documentation

Another huge time sink when working on an issue is looking things up, Googling, and wandering around the internet. So instead find a good place that has all the documentation centralized (like Dash on Mac or DevDocs online) and use that. Stop googling the attributes of input for the 50th time. Instead, with these tools, you can quickly press a shortcut to bring them up, type  html:input, for example, and have the docs ready to go offline or online — just a few keypresses away.

It’s absolutely normal to still look stuff up all the time because things aren’t necessarily worth remembering if they can be checked immediately (like HTTP status codes). But you shouldn’t have to go find the page again every time. Instead, save your future self some time and bring the documentation to you. There are even great integrations for these tools in a lot of editors, IDEs, and even Alfred/Spotlight.

Generally speaking, if you’re alt tabbing between a couple of the same applications all the time, try to think about how you can centralize them. For example, use your editor/IDE’s terminal instead of your own, or use Spotlight/Alfred to alt tabs application faster. The less you have to run around like a headless chicken between a couple of applications, the more you’ll have time and mental energy to dedicate to the current one without losing track of your thoughts. If you’ve ever alt tabbed to the wrong application 4/5 times before succeeding when you could have just popped up Spotlight, typed two letters, and then pressed enter, this is for you.

Context Switching

Finally, make it easy to quickly ship out a feature; although this is something that requires much more work. Setup continuous integration (CI) on your pull requests, have lots of tests, have even more tests, and maybe even use hub to create pull requests from the terminal. The goal is that you can pick up a feature, Just do it™, and send it off without having to worry while you move on to the next issue. CI will run and do its thing, people will review, but the more you reduce the time before/after working on a feature, the easier you make it to chain multiple issues without a hitch and easily context switch between one and the other while someone else (CI) checks it for you.

If you’re working on multiple projects, again use aliases and tools like captain to quickly up/down containers. I even personally setup project related aliases to more easily go from one to the other:

alias work_project="captain up my-project -d && code my-project-folder && open https://the-issues-board"

Think really hard about your work day and think about anything you’re doing multiple times needlessly. Can it be an alias or a shortcut? Make it one. You need to minimize the time it takes you to be functional on any given issue and the rest will come easily.

Conclusion

We’ve covered a lot of ground in this article but most of it can be easily summarized in one sentence: if you’re doing the same things all the time, don’t do the same things all the time. We spend countless hours as developers identifying patterns and abstracting them away. So apply that expertise to yourself; consider yourself a codebase in serious need of DRY-ness and take action accordingly.

What I listed here only scratches the surface. I’m by no means the fastest programmer in the world but I pay attention to it and I do believe it makes me faster than I was a few years ago. And it took very little effort to progress. So if you’re looking for good ways to have more productive days, look into it a bit. Try to see if you can ease your own load. You’ll only have yourself to thank for it in the end.