Life as a software engineer sometimes feels like trying to get to the bottom of a never-ending To-Do list. Each day fresh tickets are written, bugs are discovered, requests are made to review the latest code changes, and new technologies take over the zeitgeist. It’s a list filled with interesting items, but the sheer volume can sometimes make it hard to know what to actually tick off each day and how to move forward.
It took me a bit into my career to accept this truth. In true Virgo fashion, I much prefer lists that I can neatly tie up and bring to completion. The inability to fully quantify something was uncomfortable. Once I let go of that and dove in, I realized (also in true Virgo fashion), that I needed to figure out how to continue to swim forward in such vast, open waters. These 5 habits helped to do exactly this.
OPERATE WITH INTENTION
This is, without a doubt, the most important item on this list. It lays the groundwork for the other four — so start here!
“Intention” is one of those words that gets thrown around all the time, but what does it actually mean to operate with intention? It definitely doesn’t mean doing everything perfectly, or even doing everything, full stop. Operating with intention means making thoughtful choices about what you are doing and why you are doing it. It means being purposeful with how time is spent. It means never falling prey to going through the motions. This may all sound obvious, but the intention is easy to lose sight of in the rush of daily demands.
Operating with intention will help ensure that the work being done is quality and is in fact the work that should be getting done (“should” here be determined by the larger goals of yourself and the organization), while also allowing you to get the most out of the time spent on it. There is no formula for what this looks like, which is where intention comes in. Tradeoffs, resources and goals must constantly be evaluated. In one situation, it may be the prudent choice to take an additional month and build a more robust, scalable feature, but in another situation, such durability may not be required from the start, and the additional month might put a massive opportunity out of reach. Neither path is inherently good or bad, right or wrong, but entirely dependent on thinking through the implications before making the choice.
This applies to everything you do. If you’re going to review code, don’t spend time just “reading it” and not understanding it — this only wastes your time in the name of checking a box. Take the time to understand what you are reading if you are going to. If you are building a feature, dig into the underlying goal the feature is trying to accomplish so that you can best serve it. Whether you are trying to build the most perfect version of something or the quickest version, it must be done with intention.
LEARN A LITTLE ABOUT A LOT
Circling back to that endless To-Do list we discussed at the top, the list of frameworks, libraries, toolkits, languages, services, databases, etc. is its own abyss. This catalog is likewise overwhelming at times, and spoiler alert — you will never know everything on it. You will never know everything on it, but how do you even know what you do need to know? And how do you manage the rest of it?
You do this by learning just a little bit about as many things as you can. A little bit can be as much as writing a few lines of code and reading the docs, or as little as realizing that the new thing everyone is talking about is a toolkit for a language you don’t use, and stopping there. Exposing yourself to the broad strokes of a high volume of things helps to paint a picture of the vast landscape that is out there, provides extremely helpful context in conversation, and reins in our focus.
LEARN A LOT ABOUT A LITTLE
The flip side of expanding your horizons as widely as possible, the nature of which means it will be a shallow view, is going deep into very focused areas. An understanding of the totality of the environment can help to identify what these areas for exploration are.
Continued learning is essential to growing as a software engineer, and a great way to do this is to become an expert in what you do. If you’re a frontend engineer, it may be interesting to learn a little Java but realistically anything more than that is probably not going to be of much value from a frontend engineer to an employer. The bit of knowledge about it might be — being able to navigate a Java backend could certainly be helpful — but what really will be helpful is being an expert in the skills you are being hired for. Pick something and go deep. It can be a technology you already know but could know better (I bet you’ll be surprised to learn what you do not know) or a new tool that is additive to your current work.
READ
Reading is a wildly important part of being a software engineer. Reading is where we explore the why’s and the how’s of the code we write, and these are what really help us elevate how we think as engineers. Some of it comes as a byproduct of the job, such as reading StackOverflow or teammates’ code. But reading blogs, engineering books, technical documentation and the like is where we can really challenge ourselves through exposure to original ideas, opinions that contradict our own, and concerns we may not have even known we needed to be concerned with. I firmly believe that reading is as important to growth as writing code is.
REFLECT
I always tell engineers, particularly in the first year or so of their careers, to take the time to reflect on how far they’ve come. The more you learn as an engineer, the more you realize you don’t know, which can be disheartening. At the start of the month there were 1,000,000 things you didn’t know, but over the last few weeks you’ve worked really hard to learn about TypeScript and custom web components, and now there are only 999,998 things you don’t know — how lovely.
Reflecting on your growth brings the focus away from that bottomless pit and reframes your mindset to everything you have added to a different list, one of things that are no longer total question marks to you. This is so crucial to continuing steady, meaningful forward movement. Without it, it just feels like no progress is being made so what’s the point? Recognize all you don’t know but also reflect on how far you’ve come, and all of the skills you bring to a team.
