How to Be a Productive Developer
One dev offers a series of suggestions on how to be more productive as an application developer. From automation to shell commands, see what you should know.
Join the DZone community and get the full member experience.Join For Free
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 the like. 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 that your keyboard can do: application shortcuts, navigating the window manager, using the commandline, and more.
Especially while developing, try to use as many IDE keyboard shortcuts as possible. For every action, there is probably a shortcut. 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
@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 and then on which statements they are typing often and to set up a keyboard for these.
Talking about keyboards, please consider getting 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 to be the 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?
Equally important as keyboard usage is the approach to automating as much as possible. Computers were built to automate simple, repetitive tasks very quickly. 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 who 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. Once your feature works as expected via manual verification, convert your test into a reasonable amd automated one with proper assertions. Having that said all kinds test should ideally run without any required manual checking from a human.
Unix, Commandline, and 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 commands and type quickly enough. However, 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 of 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 hierarchies 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 home row as much as possible and to use composable movements and action commands. This is not just a pretty fast way of typing once you get used to the idea; it 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.
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 with shutting down email applications, using distraction free or fullscreen modes of the applications, muting smartphones or turning off 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.
Published at DZone with permission of Sebastian Daschner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.