sebastiandaschner blog

Working as a software developer — as well as in any other job — it’s important to be productive and to get things done. You want to increase your development speed, focus on what’s important and cut out all the cumbersome and boring, repetitive tasks.

Keyboard

The first thing to consider is that you will be more productive using your keyboard than your mouse. This is the reason why we as developers use “traditional” computers or laptops to code instead of tablets, smartphones, gaming devices and such. Once you get used to type keys instead of moving the cursor around you will notice that a mouse eventually feels unwieldy. Besides just typing text there is way more what your keyboard can do: application shortcuts, navigating the window manager or using the commandline.

Especially while developing try to remember and to use as many IDE keyboard shortcuts as possible. For every action there is probably a shortcut for that. IntelliJ has a nice feature showing which available refactoring features, navigation- and coding-shortcuts have been used so far and how often. Go to Help → Productivity Guide (or Ctrl + Shift + A → productivity) to get an impression.

Besides the built-in shortcuts there’s also the option to define own ones. Depending on the technology and frameworks you’re using there is always room to improve and type less. For instance I’ve instructed IntelliJ to enhance ijt<Tab> to @Inject including the correct import — a statement you’ll have to type rather often in Java EE applications. I encourage everybody to reflect every now an then which statements they are typing often and setup a keyboard for these.

Talking about keyboards, please consider to get a proper one. Once you know what great kinds of typing feedback are out there you may never want to go back to a cheap device. Especially when you want to increase your keyboard usage it totally makes sense to invest into a good one — ideally a mechanical keyboard or one with capacitive switches. I personally found the Cherry Brown and Topre switches best for me. Keyboards with three-digit prices may sound like expensive toys, but as developers we use these things for a lot of hours per day — a carpenter wouldn’t also buy the cheapest tools in the DIY store, would they?

Automation

Equally important as keyboard usage is the approach to automate as much as possible. Computers were built to automate simple, repetitive tasks very fast. They outperform every human in those things — humans however are better at thinking :-) Shell scripts and macros in all kind of variations are your friends and should be used as much as possible.

A good approach is to stand back once in a while and reflect which tasks and actions you’re doing the whole day and what can be automated and improved. This may be launching applications, using menus with the mouse instead of shortcuts, manually applying the same actions or typing the same commands all over again, typing long shell commands a lot of times instead of using aliases and so on. Try to be lazy here — that’s a good thing in this case.

A very good story to share is the one of a creative system administrator — he automated everything from instructing the coffee machine to answering emails. This gives you some impression of how computers can be used to automate as much as possible — try at your own risk :-)

Once you develop applications you (hopefully) are thinking about how to test them as well. The tests however should be automated as well and run fast. Try to avoid manual assertions as well as manual repetitive testing. Which these constraints you can enhance your test suite over time, still have fast feedback loops, as everything runs automated and yet have a sophisticated regression test coverage.

If you’re starting to develop an application or just a functionality, instead of a temporary public static void main consider writing a unit test instead. Once your feature works as expected — via manual verification — convert your test into a reasonable, automated one with proper assertions. Having that said all kinds test should ideally run without any required manual checking from a human.

Unix, Commandline & Vim

No matter what you’re doing on the computer, there’s probably a shell command for that — especially when using Unix. You can get rid of a lot of GUIs (even the file explorer) when using the CLI. At first people usually struggle to remember all the shell command and type fast enough, but once they get into it and support their approach with shell aliases and shortcuts they will be more productive very soon.

I can only recommend every developer to get in touch with their shell, Unix commands, piping and bash (or maybe Python) scripts. Even on Windows you can use Cygwin or Bash on Windows to have a proper and usable shell. Speaking about shells, if you’re on Linux you’re pretty likely using bash. If so give zsh a try, it is backwards-compatible with the bash commands, i.e. you can continue to use the same commands as before, but it ships with some really nice features like switching directories without cd, auto-completion of directories of multiple hierachies at once or suffix aliases. I tried it once after reading some articles about it and I never switched back to bash.

One of the most important things I’ve learned last year was the Vim way of typing after I (finally) gave the Vim editor a try. The main idea is that you keep your fingertips on your homerow as much as possible and use composable movements and action commands. This is not just a pretty fast way of typing once you get used to the idea but also changes the way of thinking about keyboard productivity. There are tutorials out there that describe the concepts way better than I could in the scope of this post and I encourage all developers to at least give it a try.

When I started getting familiar with it — after roughly two weeks — I changed my command line to Vim-mode and even my Linux window manager to a Vim-like controllable tiling one, i3 in my case. A lot of applications support Vim-like keybindings or provide plugins for that.

Focus

Of course when talking about productivity there is way more than just the craftsman techniques. As developers need to focus and “get into the zone” for coding tasks that require concentration, we should ideally work in an environment that minimizes distractions. This starts from shutting down email applications, using distraction free or fullscreen modes of the applications, muting smartphones or turning of unnecessary notifications and goes on to the workplace itself to the colleagues working in the same room. Sometimes it makes a lot of sense to just go into a quiet environment without any distractions to get important things done. I personally like quiet offices in the morning, home office, crowded cafés (with headphones) or intercontinental flights.

Conclusion

Do you have any specific tools or approaches that increased your productivity? Please let me know, feedback is highly appreciated.

Update: Also have a look at my video course about developer productivity.

 

Found the post useful? Then you might enjoy my Developer Productivity Masterclass.