4 easy software program engineering habits that remodeled my productiveness
“Your outcomes are a lagging indicator of your habits.” – James Clear
As I turned a greater software program engineer, I observed 4 key habits in my every day workflow that had made me way more productive.
Pleasant plug: SWE Quiz is a compilation of 450+ software program engineering and system design questions overlaying databases, authentication, caching, and so forth. They’ve been vetted by engineers from Google, Meta, Apple, and extra.
I’m a core contributor to SWE Quiz and it’s helped lots of my friends (together with myself) cross the “software program trivia questions” throughout interviews and really feel extra assured at work.
“Move” is the foundation of productiveness when programming.
Since software program engineering is a “maker” activity the place I’m producing one thing, I usually carry out finest when I’ve a big block of uninterrupted “circulate” time to work on a challenge.
Nevertheless, it may typically be actually exhausting to get into circulate for those who’re caught scrambling on what duties your challenge objectives entail. Ambiguity is tough to cope with. Not even understanding the place to start out could make reaching that “circulate state” a lot tougher.
Every profitable motion snowballs into extra.
There are a number of methods I exploit to do that:
-
Cease proper earlier than a “sticking level.” A sticking level is a job that’s a part of a challenge the place I do know the steps to do to finish it, however I don’t know if there are hidden prices.
-
For instance, if my sticking level is deploying my ML mannequin and HTTP server to a dev occasion and verifying that it processes requests correctly, then the hidden prices are deployment errors, authentication errors, useful resource constraints, and so forth.
-
-
Write down the following steps extraordinarily clearly. Writing down steps makes regaining context and the mind-set from the day earlier than simpler.
My first expertise with an actual “shortcut ninja” was truly not with a software program engineer. It was with my funding banker pal, who sped round his Excel sheets with out ever touching the mouse.
After that, I took the time to study keyboard shortcuts, to the purpose the place I seize my mouse ~60% lower than I used to. (Sure, I tracked this.)
Each editor and power in my workflow has keyboard shortcuts for just about any motion you’ll be able to consider. This doesn’t simply apply to your IDE, but in addition your model management techniques, your net browser, and your docs.
For instance, my IDE has a linter/formatter/cleaner multi function shortcut, which I exploit typically as I write code to ensure traces keep neat.
I generally use Command/Ctrl + Shift + V to stick in textual content with out formatting in docs and chats.
Urgent
.(interval) on a GitHub repo web page will robotically open up the repo in a VSCode Net occasion.
Once I do want to the touch my mouse, it’s configured with shortcuts additionally. I’m fortunate sufficient to have a mouse with buttons on the edges. I’ve programmed these buttons to modify between Areas on my Mac, although you’ll be able to program them for no matter feels intuitive for you. (You possibly can even program them to be completely different per program.)
One of the simplest ways to study shortcuts? Introduce the most typical elements of a program that you simply use, one a time.
For instance, if you end up right-clicking to format your code typically, that may be the primary one you “apply.” Occasionally, add a brand new shortcut to your repertoire and use it naturally as you code all through the weeks. Over time, the shortcuts might be muscle reminiscence.
I generally must run a set of widespread instructions on my terminal.
I’ve sure pages that I at all times go to and a few notes about varied languages that I at all times come again to. For instance, I concurrently use templates too hardly ever and but too typically when writing C++, that means I often have to reference the docs when utilizing them.
As an alternative of digging round documentation pages or always wanting by my terminal historical past, I hold instructions and customary doc lookups in a large doc with one phrase describing the command. I name it my Huge E book of Instructions, which is round ~10 pages lengthy now. I’m simply capable of finding any command I want with a fast Ctrl+F. Then, a Shift + Command + ➡️ is a full line-select for a straightforward copy-paste.
I even have a number of widespread macros programmed into my keyboard for the instructions and phrases, like hard-to-remember ACL teams. Typically, I make the most of Terminal aliases.
My pal
wrote an amazing article that dives into his personal workflow suggestions, which begins off with an amazing primer into aliases, keyboard shortcuts, and instruments: The top 7 software engineering workflow tips I wish I knew earlier 🧰
That is much less straight programming associated, however I discovered to say “no” to issues.
I stated no to novel expertise when boring expertise would do the job.
I stated no to automating one thing when it solely wanted to be executed as soon as manually.
I stated no to extra duties once I knew I used to be already overloaded with work (although my people-pleasing thoughts pleaded to take them on).
I stated no to scope creep advised by our designers.
I stated no to low-impact duties.
Studying to say no was tougher than I anticipated, but one of the vital helpful expertise I’ve utilized in each the office and in my private life.
Typically, it’s painful to say no to issues. In each my profession, hobbies, and private life, there are occasions I say no to issues I actually wish to do. However I don’t as a result of I do know my time and vitality is healthier spent on what I’m at the moment specializing in.
It’s a cliche to cite Steve Jobs, however I remind myself of his well-known quote “focus is about saying no” typically.
My pal
additionally has a improbable article about saying no, which I extremely advocate: The Software Engineer’s guide to saying “no”
While you’re prepared, here is how I may also help:
SWE Quiz is a compilation of 450+ software program engineering and system design questions overlaying databases, authentication, caching, and so forth. They’ve been vetted by engineers from Google, Meta, Apple, and extra.
I’m a core contributor to SWE Quiz and it’s helped lots of my friends (together with myself) cross the “software program trivia questions” throughout interviews and really feel 10x extra assured at work.