If you spend any amount of time on the internet these days, it’d be easy to believe that Software Engineering is a dead career. AI can write code pretty great now, and because of that, people seem to think we don’t need Software Engineers anymore.

I’m here to tell you: Writing code is not, and has never been, the main job of a Software Engineer.

The real job has always been two things: Listen and Imagine.

Listen

First and foremost, your job is to listen. To find as many ways as you can to learn about your users. To figure out why they’re using your product, what problems they’re trying to solve, and what’s getting in their way.

This means spending as much time as you can with your customers. Watch them use your product. Set up calls with them. Go to their office for a day and work in their conference room. Watch quietly, listen to them use your product. Empathize with the problems they are trying to solve.

Every engineer has users. To be clear: a user isn’t always a paying customer. Platform teams’ users are the product teams at their company. DevX teams have the company’s engineers. Find your user, the person using your product every day, and listen to them.

The best engineers I know aren’t the ones writing the cleverest code. They’re the ones who deeply understand the problem they’re solving, because they’ve listened.

Imagine

The second part of the job is to imagine. Imagine what the future could be like for your users. Take what you have heard, and connect it to what you think you can build. Imagine how it will fit into your tech stack, and how your tech stack will need to grow to support extensions of those ideas.

Your users won’t always know what’s possible. Their ideas on what you should build will often be wrong. A user is likely to be asking for a better horse, you should be trying to build them a car. They don’t spend all day every day building new things, that’s your job.

The people experiencing the problems don’t always know what’s possible. They don’t know that a task taking them 20 minutes could take 2 seconds. They don’t know that three disconnected spreadsheets could be one live dashboard. That’s not their job to know. It’s yours.

To do this right it takes a firm understanding of what you’ve built so far, and what you could build on top of it. Your role is to be the “steward of the machine”. To shape and mold the technology to meet your user’s needs.

When you combine deep listening with a broad understanding of what technology can do, you become the bridge between “this is frustrating” and “this is solved.”

In Practice

Here’s a recent example from my work at hi finance.

My operations team called me into a meeting. They were designing a new grant application process and had a problem: gathering information from clients required a full meeting just to ask a few questions. They wanted to know if we could send clients a survey instead.

My job in that moment wasn’t to build a survey. It was to listen.

I asked questions. I learned about the full process: the back and forth, the essay writing, the follow-up meetings. I understood what they were really trying to solve: reduce friction for clients while still getting the information they needed.

Then I imagined something better than what they asked for.

Instead of a boring survey with text fields, what if we made it an audio experience? Quick voice prompts. Brief spoken responses. Something that felt more like a conversation than a form. Something that might actually bring a little joy to the process.

That’s what we’re launching this week. Not because of the code I wrote—but because I listened to the problem and imagined a solution they couldn’t see yet.

vs. Product Management

A lot of what I have discussed here is blending the line between the role of a product manager and the role of an engineer. This is done with intention. I have always believed these two roles to be deeply similar. Both are responsible for delivering a great product to their users.

The engineer however is also responsible for the machine. For growing and shaping the machine to meet the users needs where they are. As the saying goes: “Anyone can build a bridge that stands, but it takes an engineer to build a bridge that barely stands”. In the era of AI this is especially apt. The role of the engineer is to understand the technical tradeoffs that are being made, and make sure they align with the business context. A pure product manager with a prompt is likely not going to have the required depth of expertise to do this well.

The Tools Change. The Job Doesn’t.

Software engineering isn’t dying. The tools we use are changing, but they’ve always changed. Assembly gave way to C, which gave way to Python, which is now sharing the stage with AI-assisted coding.

Each shift has made certain tasks easier and freed us up to focus on the harder parts, the parts that require understanding people, not just syntax.

I am actually so excited to be an engineer in the era of “vibe coding”. The tools we have today mean I get to spend more time doing the part of the job I love: building technology to make people’s lives just a little easier. And that part of the job is not going anywhere.

Shameless plug

If you are a software engineer who’s interested in building great products and wants to help students manage their finances, reach out to me at: mike@hfinance.ca

If you do or don’t agree with this post also feel free to email me at: mike@hifinance.ca