5 Years as a Software Engineer

October marked my fifth anniversary as a full-time software engineer! 🎉 After five years of projects, coworkers, clients, and code, I wanted to share some general observations about entering into this world for anyone else considering a career change.

The Good

Building stuff is fun.

Five years in, I can still say: nothing beats the satisfaction of writing some logic and watching a program or a process run successfully. Hands down, the best part of any week is when I get to take a list of requirements and figure out how to make it work.

You won’t get bored.

If your greatest work fear is a dull day punching the clock: this might be the field for you. There is constantly something new to learn, and if you feel like you’re starting to stagnate in a role, there’s always another project (or, if necessary, a new job) around the corner.

Constant learning makes you see the world differently.

You don’t become a better engineer just by memorizing languages or data structures; you become a better engineer by learning how to learn faster, by getting over your fear of making mistakes when you’re trying something new, and by learning how to analyze a new problem and break it down into approachable steps.

I find this mindset also carries through into other parts of life, and has opened up a new world of possibilities for me. Everything that once seemed intimidating or impossible to understand now seems learnable with enough effort.

There’s a lot of room to define a role you love.

Software is a crucial underpinning of everything in our modern world—and that means, no matter what your interests are, there’s probably a role that combines them with writing code.

There are also many ways to use your technical skills. If you like writing code all day, you can stay on an Individual Contributor track. If you like people and organization too, you can lean into Engineering Management or Technical Program Management. Or if you care most about the product you’re building, you can move into Product Management. Even if your hands aren’t on the keyboard everyday, it’s really helpful to have an understanding of how software gets built.

The Bad

Sedentary days creep up on you quickly.

It’s not just the work hours filled with coding; it’s also the video calls at your desk, the ability to work from home instead of commuting (which, at least for me in NYC, used to involve a fair amount of walking), and the hours of learning to keep up with new tools and skills (most of which also happens… sitting at your desk). Standing desks help, but only to a point. Desk treadmills and bikes look great on TikTok, but can be a little impractical in reality. Sitting in front of a computer all day is just bad for your health unless you’re ready to fill your free hours with a lot of activity.

Thinking like a computer changes your brain.

No one should embark on this career without understanding the basic concept of neuroplasticity: our brains adapt to whatever we ask them to do most often. When you spend your whole day writing instructions for computers, your brain starts to see everything you encounter in terms of logic, process, efficiency, and task completion.

But there’s so much more to being human! Don’t let yourself become a robot; seek out art, literature, human connection, and creative hobbies to keep yourself balanced. (And read more about this in 📒The Shallows — it really changed how I structure my days.)

Beware of the toxic productivity trap.

Data-driven industries can be pretty unforgiving to humans. When we try to optimize and account for every minute of the day, and when we work on tightly scheduled teams where every todo is a blocker for someone else, it doesn’t leave a lot of space for the occasional plain old-fashioned “bad day,” when you’re just not at your best. (Because, you know… you’re not actually a machine.)

There’s no easy solution to this, but I really try to set boundaries to prioritize my well-being. No matter how exciting the project, I don’t want to work with any team that doesn’t put empathy first. And I’ve learned to try to estimate my work based on my average day, not my best day.

It’s impossible to keep up, but you have to try.

To survive in this industry, I think you have to take a lesson from sharks: if you stop moving forward, you’ll die. Technology is constantly changing, and it moves faster and faster every year. Languages come and go, paradigms shift, and sometimes it’s hard to predict which new trend will gain enough traction to change the whole industry.

That’s a lot of pressure to keep up (and all without losing steam on day-to-day work tasks). The only path I see to staying relevant is to never stop learning, and to never stop polishing the skills that have been essential to every project I’ve worked on: breaking down problems in order to solve them, and working with people.

The Unexpected

I don’t actually write code all day.

In fact, the most time-consuming (and difficult, and exhausting) part of my job is nailing down requirements to get started: working with the whole team to make sure we all share an understanding of the problem at hand, the desired outcome, and how we want to use technology to reach the solution. After all that, writing code and getting the system working is usually the easy part.

Many software engineers don’t work for big tech companies or start-ups.

And they’re not on Twitter. They’re not “moving fast and breaking things.” They’re quietly working within bigger companies and small agencies, building the most stable tools they can to minimize long-term risk, finding ways to solve real world problems with languages and frameworks far from the cutting edge.

Communication and organization skills are underrated.

When you start working as an engineer, you might think your technical skillset is the most important thing to focus on to advance your career. It’s true that tech skills are important, but the most talented and successful engineers I’ve worked with — the ones who are the linchpins of a project’s success — know that the tech skills are the easy part. The people who really push a project forward balance tech skills with communication, vision, and organization.

If you want to accomplish anything bigger than what you can build yourself, it’s not enough to have a solution in your head; you have to be able to show it to your team, prove out its advantages, and onboard new team members as quickly as possible to carry your vision forward.

Everybody’s figuring this out as they go.

This field moves way too quickly for most working professionals to have deep expertise in every tool on every project. The best we can aim for is to keep up our expertise in a few tools we use most often, stay competent across others that pop up sometimes, and most of all, stay strong on our foundational problem-solving skills.

There’s much more to say about this work, and I’m certain my experience is not universal, but I hope this is helpful if you’re considering making coding a career!

Cover photo by Christopher Gower via Unsplash.