4 Simple Software Engineering Habits That Transformed My Productivity
4 simple software engineering habits that transformed my productivity #
Excerpt #
A breakdown of 4 simple software engineering and coding habits that improved my productivity. These include keyboard shortcuts, learning to say no, reaching flow state faster, and keeping a big book of commands handy.
“Your outcomes are a lagging indicator of your habits.” - James Clear
As I became a better software engineer, I noticed 4 key habits in my daily workflow that had made me much more productive.
SWE Quiz - Lifetime Access to 450+ system design questions #
Friendly plug: SWE Quiz is a compilation of 450+ software engineering and system design questions covering databases, authentication, caching, etc.
They’ve been created by engineers from Google, Meta, Apple, and more.
It’s helped many of my peers (including myself) pass the “software trivia questions” during interviews and feel more confident at work.
1. Leave work slightly unfinished for easier flow the next day #
“Flow” is the root of productivity when programming.
Since software engineering is a “maker” activity where I’m producing something, I generally perform best when I have a large block of uninterrupted “flow” time to work on a project.
However, it can often be really hard to get into flow if you’re stuck scrambling on what tasks your project goals entail. Ambiguity is difficult to deal with. Not even knowing where to start can make reaching that “flow state” much harder.
Each successful action snowballs into more.
There are a few techniques I use to do this:
Stop right before a “sticking point.” A sticking point is a task that’s part of a project where I know the steps to do to complete it, but I don’t know if there are hidden costs.
- For example, if my sticking point is deploying my ML model and HTTP server to a dev instance and verifying that it processes requests properly, then the hidden costs are deployment errors, authentication errors, resource constraints, etc.
Write down the next steps extremely clearly. Writing down steps makes regaining context and the state of mind from the day before easier.
- Make them actionable and unambiguous.
[
2. Get better at keyboard and mouse shortcuts #
My first experience with a real “shortcut ninja” was actually not with a software engineer. It was with my investment banker friend, who sped around his Excel sheets without ever touching the mouse.
[
This, except I finally did appreciate it years later. Source: Work Chronicles
After that, I took the time to learn keyboard shortcuts, to the point where I grab my mouse ~60% less than I used to. (Yes, I tracked this.)
It’s not just me! Sam Altman has a quote on this in his Productivity essay:
I also made an effort to learn to type really fast and the keyboard shortcuts that help with my workflow.
Every editor and tool in my workflow has keyboard shortcuts for pretty much any action you can think of. This doesn’t just apply to your IDE, but also your version control systems, your web browser, and your docs.
For example, my IDE has a linter/formatter/cleaner all in one shortcut, which I use often as I write code to make sure lines stay neat.
I commonly use Command/Ctrl + Shift + V to paste in text without formatting in docs and chats.
Pressing
.(period) on a GitHub repo page will automatically open up the repo in a VSCode Web instance.
When I do need to touch my mouse, it’s configured with shortcuts also. I’m lucky enough to have a mouse with buttons on the sides. I’ve programmed these buttons to switch between Spaces on my Mac, though you can program them for whatever feels intuitive for you. (You can even program them to be different per program.)
The best way to learn shortcuts? Introduce the most common parts of a program that you use, one a time.
For example, if you find yourself right-clicking to format your code often, that can be the first one you “practice.” Every so often, add a new shortcut to your repertoire and use it naturally as you code throughout the weeks. Over time, the shortcuts will be muscle memory.
3. Keep a list of searchable commands and links handy #
I commonly have to run a set of common commands on my terminal.
I have certain pages that I always visit and some notes about various languages that I always come back to. For example, I simultaneously use templates too rarely and yet too often when writing C++, meaning I usually need to reference the docs when using them.
Instead of digging around documentation pages or constantly looking through my terminal history, I keep commands and common doc lookups in a giant doc with one word describing the command. I call it my Big Book of Commands, which is around ~10 pages long now. I’m easily able to find any command I need with a quick Ctrl+F. Then, a Shift + Command + ➡️ is a full line-select for an easy copy-paste.
I also have a few common macros programmed into my keyboard for the commands and terms, like hard-to-remember ACL groups. Sometimes, I utilize Terminal aliases.
My friend
wrote a great article that dives into his own workflow tips, which starts off with a great primer into aliases, keyboard shortcuts, and tools: The top 7 software engineering workflow tips I wish I knew earlier 🧰
4. Say “no” more #
This is less directly programming related, but I learned to say “no” to things.
I said no to novel technology when boring technology would do the job.
I said no to automating something when it only needed to be done once manually.
I said no to more tasks when I knew I was already overloaded with work (even though my people-pleasing mind pleaded to take them on).
I said no to scope creep suggested by our designers.
I said no to low-impact tasks.
Learning to say no was harder than I expected, yet one of the most valuable skills I’ve applied in both the workplace and in my personal life.
Sometimes, it’s painful to say no to things. In both my career, hobbies, and personal life, there are times I say no to things I really want to do. But I don’t because I know my time and energy is better spent on what I’m currently focusing on.
It’s a cliche to quote Steve Jobs, but I remind myself of his famous quote “focus is about saying no” often.
My friend
also has a fantastic article about saying no, which I highly recommend: The Software Engineer’s guide to saying “no”
When you’re ready, here’s how I can help:
SWE Quiz is a compilation of 450+ software engineering and system design questions covering databases, authentication, caching, etc. They’ve been vetted by engineers from Google, Meta, Apple, and more.
I’m a core contributor to SWE Quiz and it’s helped many of my peers (including myself) pass the “software trivia questions” during interviews and feel 10x more confident at work.