As software developers, we always want to improve ourselves continuously. It can be through writing cleaner and more efficient code, using new design patterns, expanding our stack, or deep-diving into a specific technology.
We strive to improve; we’re encouraged to do post-mortems with action items and to keep asking what went right and what went wrong. We’re also encouraged to have sprint retros so we’ll do better next time. We always ask for feedback, either through code reviews or as part of a 1:1 with our team lead.
If you feel like you’ve reached a plateau, and you’re not learning anything new sprint over sprint, you should take a proactive approach and do a post-mortem on yourself (sorry for the grim analogy)! Meaning, find your weak spots and optimizing where possible to deliver more value faster.
What I want to focus on in this article is dev velocity and efficiency – two areas where any developer can always improve. When I say velocity I am not only talking about your speed of typing (but if you really want to, you’re welcome to see how you measure on a typing speed test) but rather the speed at which you push new code to prod and the amount of time it takes to debug.
Before jumping into my methods I want to emphasize that the main guideline that should be your northern star is – to use anything that makes you faster! Even if it is not “mainstream” or considered “noob-like”.
For example, most developers only use Git CLI and are hesitant to use the Git UI out of fear of being labeled as “unprofessional”. I can say with confidence that for many use cases, the UI is much faster than using the CLI.
How come? I’m glad you asked! When commenting only on specific files/lines, resolving conflicts, viewing the changes, and cherry-picking, I combine both UI and CLI. For each scenario, I ask myself – What’s faster right now?
There are great Git tools such as GitKraken, Sourcetree, and my personal favorite – GitHub Desktop. Using them interchangeably makes my life easier and my work much more efficient.
So, what else can be done to improve your velocity? Keep reading.
Don’t be a programmer, be a problem solver
It sounds like a cliche out of a corporate motivational poster, but many devs start writing the code before they solved the problem.
Many times we jump right into the technical nitty-gritty, despite the fact that most of the time, all we need is a simple solution. Every great architect’s design is very complex in the beginning and has many moving parts until the architect gets a design review. After the review, the architect shrinks to only necessary, simple, and small bits of components.
We are also masters of doing the unnecessary. A great example of that is the congestion of E2E tests. E2E tests are very expensive to write and maintain, while for most use cases a simple unit/component/integration test would provide the same value, and in other cases, it’s completely redundant.
Devs can act like a Roomba sometimes – getting stuck in front of a rug, instead of going around it. In our world, this is akin to finding a bug and immediately jumping on it, relentlessly trying to round the square.
Over the years Roomba’s tech improved drastically. Don’t be like a 2003 model that keeps crashing into the wall repeatedly. Become a 2030 model that knows how to see the full picture, adapt, improvise, and get things done in the most efficient manner.
Turn off your computer. Grab a pen and paper
Devs tend to start coding before they think. As I said earlier, we’re eager to tackle the problem. However, it should be the other way around! Before you start anything, try to take 5 minutes in order to sketch a few diagrams of what you are planning to do. I promise you that those 5 minutes will pay off many times over. If the thinking process is accurate – it will lead to minimal and quick solutions, as well as faster error detection.
Picture a chess grandmaster. They can draw a mental image of the board for the next 30 steps, and take their next step based on that image. If we become more like professional chess players we could predict deadlocks, race conditions, wasted code, and much more.
Master your environments and tools
IDEs and tools differ from developer to developer, even within the same team. But remember – Do whatever makes you faster! Always try to explore new tools, maybe they are better for you and can save you precious time. On the other hand, try to avoid redundant tools and disruptions. Now that you’ve compiled your ideal toolbox it’s time to master them. And by that, I mean that you should know all of their:
- Capabilities & vulnerabilities
- Shortcuts (more details below)
- Extensions (more details below)
- Custom configurations to increase speed & efficiency
Furthermore, you need to master your local environment. From my experience, developers spend a lot of time troubleshooting their local env and can get frustrated very quickly. You should feel comfortable within your own castle when you’re able to:
- Troubleshoot fast & efficiently
- Master the programming language ecosystem
- Create helpers – scripts in bash/python, makefiles, predefined docker-compose, etc…
- When adding new tech, remember to support it well within the local environment
Know your shortcuts!
As developers, we need to aim to keep our hands off the mouse but never off the keyboard. And when we’re on the keyboard we must know the shortest way to go from A to B. Go from the beginning of the line to the end, from the browser to the terminal, from taking a screenshot and sending it to your colleagues over Slack.
What shortcuts should you learn? Learning shortcuts is a never-ending race, there is basically a shortcut for anything, so where to stop? The answer is simple, if your hands are mostly on the keyboard it’s a sign you have room for improvement.
There are 3 main areas where knowing shortcuts pays off the most:
- OS
- IDEs
- Major interfaces like our web browser, terminal, Slack, etc.
Whenever I switch to a new IDE I follow the following steps:
- Create a doc file with the 20 – 30 most common shortcuts that I will probably need
- Print the doc and practice it while working for several days until I master the shortcuts
- When I come across a point that is ineffective, I search for a relevant shortcut. And if I can’t find one I simply create it myself
All of that shouldn’t take me more than a few minutes to do, and I’ll earn back that time every day from now on.
Create aliases and shortcuts
Every day we do repetitive tasks. Sometimes, you’re basically running a manual playbook. We use Git repetitively, our IDEs, terminal, files manager, OS, and so on. I encourage you to add aliases and shortcuts to your terminal. Each alias is supposed to be 1-6 letters max.
Common alias I would add:
- Git common actions – like pull, create branch, merge, etc.
- Docker commands – like build, tag, docker exec -it /bin/bash ….
- Aliases for major CLI tools that you’re using, like kubectl
- For opening applications or important directories, i.e open Vscode code.
My favorite alias is (open pull request for a single commit):
gpp='f() { ga . && gc -m $1 && gpsup && sleep 1 && gh pr create --fill };f'
It relies on you to download the GitHub CLI tool (gh) and configure it, to be able to add other aliases:
ga='git add' gc='git commit' gpsup='git push --set-upstream origin $(git_current_branch)'
gpp "Do all the work for me"
Invest in your IDE, terminal, and browser
The vast majority of applications we spend our time on are in the IDE, terminal, or browser so this is why it is so important to optimize our work in all of them.
One important thing to note is to configure your IDE debugger properly. Many times devs tend to get lazy and only print logs. I agree that on-session debugging will be effective, but not in many other cases.
I recommend searching the internet for the extensions that best suit your needs. Here are the extensions that I’m using:
VScode:
- Enable `Editor: Format on save` in the user settings
- Code spell checker
- Prettier
- Auto Rename Tag
- Markdownlint
- Material Icon Theme
- Any extension for your programming languages and markup languages
- Configure formatters and linters for the language
- Node.js
- Golang
- Python
- Web development
Zsh ( zsh allow you to put extensions, I also recommend using iTerm as your terminal of choice)
- oh-my-zsh
- zsh autosuggestions
- zsh-z
- Fig ( for MacOS users)
The new era of AI
You’ve probably heard of, and already used ChatGPT or something similar. I was really skeptical at first about how much AI tools will actually help me. One such tool that I liked a lot is GitHub Co-Pilot. The reason I love it is that it doesn’t force me to do anything rather than press the TAB button. Very easy to install and doesn’t cost too much. I am sure that your manager will approve the budget for it (my manager was the one who introduced me to the tool!) I found it extremely useful for tests, naming, boilerplates, short functions, etc.
