A defining trait of us humans, is the ability to make, and use tools. We’re not alone, of course, but we’re so far the most successful species (for a reasonable definition of successful). This begs a couple questions:
- What tool do you use the most?
- Which is your favorite?
- How would you feel if it broke, was deprecated, or otherwise disappeared?
I recently ran a presentation on tooling at my job. We’re exploring automated tooling for our C++ continuous delivery and continuous integration (CI/CD) pipelines. However, I decided not only to focus on automated tools, but also the manual tools. The sentiment I wanted to share was: care about what you’re using.
What do I mean by that?
A carpenter has a toolbox. The sturdiest is their hammer. After years of practice, they know how to angle, and how hard to swing the hammer, to best knock in a nail. Software engineers are the same. We use tools every day, for years on end. Be it editors, terminals, shell commands, web browsers, and more. Do we use these optimally? Do you? I don’t.
How do you think about code editors?
If you use Visual Studio Code (VS Code), do you rely on using the mouse for most things, such as moving up and down in your code, navigating between files, running actions, and switching to the integrated terminal? Then stop. You’re doing yourself a disservice. With the default keybindings, get familiar using the Show All Commands by typing Ctrl+Shift+P (Cmd+Shift+P on Mac). This allows you to do practically anything within the editor, without touching your mouse. The menu also give hints for common keybindings. Rebind to what best suits your workflow.
But keyboard shortcuts are not the only improvement. There are extensions. If you’re colorblind, there are high contrast themes. Make the tool your own. The more time you invest, the more you care. The more you care, the better it gets. And when in doubt, consult the documentation.
If you can’t improve your use of VS Code, or whatever editor you’re using, try a new one. And as you try something new, don’t retrofit what you’re used to. Break your habits. You might have some bad ones, this is your opportunity to grow. Use this new editor for a month, two, or three, and if you still want to move back, you can. You’ve learned something new about yourself, your workflow, and how editors work in general.
Do you navigate Git graphically?
Maybe you’re using Gitkraken, smartgit, or GitHub Desktop. You might use some other tool. How would you replicate your actions from the graphical tools, in the Git command line interface (CLI)? If you don’t know, read the Git book by Scott Chacon and Ben Straub.
Likewise, if you only use Git in the terminal, expand your perspectives and explore one of the listed graphical tools. I’m currently exploring Gitkraken, again, after a long period of only using the Git CLI.
Git, and other version control systems, are tools we use every day. The way they enable us to collaborate with others, and how we ourselves care about how we collaborate with others, make or break a successful partnership.
I encourage you to explore the capabilities. You can configure Git to be personalized, matching your preferences. If you habitually rebase, try a merging workflow. Experiment with git-flow, GitHub Flow, and other workflows. You may find something you like.
Manual labor, or automated bliss?
I’m biased. I dislike doing the same thing over and over. I don’t want to have to think about how many spaces a specific line should be, to properly align with the context around it. People want brackets in different locations. These decisions should be taken at team or company level, and then be enforced by automatic formatters.
You should also ensure that the enforcement runs on two levels. First, locally, so no commits run unformatted. Use pre-commit set up to run your formatters for this. Second, in your CI/CD pipelines, to ensure no rowdy developers that have forgotten to set up pre-commit on their machine, or someone who disagrees with the set up, affects everyone else. Run the enforcement in your pipelines, and your disagreements in meetings.
Formatting is only one level of quality assurance, and is limited to the developers; linters and checkers assist with visible quality for other stakeholders. Run these tools like you run formatters. The linters help with performance, consistency, and best practices.
The web isn’t designed for the keyboard
There is a lot on the web that isn’t well-adjusted to keyboard-only navigation. This is primarily caused by mobile-first designs, and a simple fallacy of thinking everyone can use the mouse. This is just a fallacy. Websites should be designed with accessibility in mind, and it’s not just for the people with no other options.
When a website is designed with keyboard-navigation in mind, several tools open up for the power user to get around quickly. Use Tab, and Shift+Tab, to jump back and forth. Today, this would infuriate you. Tomorrow it might not. But there’s a solution, available today.
Get a Vim-inspired plugin for your browser. There are a couple. I use Vimium C for Firefox. This allows me to hit hyperlinks without repeatedly hitting Tab, and without using my mouse. On several occasions, I’ve forgotten to turn on my mouse. This doesn’t, however, always work. Some websites use clever JavaScript to make non-interactive elements interactive, without giving the browser a hint, which render keyboard-oriented tools moot.
If you’re a web developer, please, read and follow the guidelines published by the Web Accessibility Initiative (WAI).
Actively participate in using your tools
Keep yourself aware of changes. Tools update over time. Read the changelogs, and you might find something new. Or something you’ve been missing. Read the friendly manual. Most importantly, dive deep into what you use and don’t force old habits on new friends. A previously unsolvable problem may suddenly be handled in mere minutes. Shape your tools, and they may shape you.
seffra (dot) dev 