Career

Breaking Into Software Engineering: How the Industry Has Changed

I started in this industry in the early 2000s with a diploma from Aptech and a mathematics degree, in a job market that judged you almost entirely on whether you could write correct code under a deadline. Today I lead technology for a supply chain company, having spent 22 years moving from developer to lead to architect to executive. I get asked a version of the same question often, usually from someone early in their career or trying to break in: is it still worth starting now, when AI can write code faster than I can? My answer is yes, but the path in looks different than it did for me, and pretending otherwise does newcomers a disservice.

What Hasn't Changed

Fundamentals still matter, arguably more than ever. Data structures, how a database actually executes a query, what happens across a network boundary when a request fails halfway through, how to read a stack trace and reason backward to a root cause — none of that became optional because an assistant can autocomplete a function. If anything, I've watched the opposite happen on my own teams: engineers who lean on AI-generated code without the fundamentals to evaluate it produce more bugs, not fewer, because they can't tell when the output is subtly wrong. The floor for "can produce code" dropped. The floor for "can be trusted with a production system" did not.

What Actually Changed

The barrier to writing your first working program is lower than it has ever been. When I started, getting a "hello world" running across a network took real persistence — documentation was thinner, communities smaller, and a wrong turn could cost you a full evening. That friction is mostly gone now, and I think that's an unambiguous good for newcomers. But the barrier that replaced it is judgment: knowing whether the code that was generated for you is correct, secure, and appropriate for the problem, and knowing what questions to ask when you're not sure. That's a skill built through practice and feedback, not through prompting, and it's the thing hiring managers like me are now screening for more than raw syntax fluency.

Interviews are shifting accordingly. I've changed how I evaluate candidates over the past two years — less "write this algorithm on a whiteboard," more "here's a piece of code, tell me what's wrong with it" or "walk me through how you'd debug this production incident." The value has moved from production to verification and reasoning, and that shift is only going to accelerate.

The industry stopped asking "can you write this" as its primary question. It's asking "can you tell when something is wrong" instead.

What I'd Actually Do Differently Starting Today

First, don't skip the fundamentals because a tool can paper over the gap. Learn to read code as deliberately as you learn to write it — take an open-source project, trace a feature through it end to end, and explain to yourself why it's structured the way it is. That skill transfers directly to evaluating AI output, which is now a core part of the job regardless of your title.

Second, build real things with real constraints, even small ones. A side project that has to handle actual users, actual data, and actual failure teaches you more in a month than a tutorial series teaches in a year, because it forces you to make trade-offs instead of following instructions. When I look at junior candidates, the ones who stand out aren't the ones who used the flashiest stack — they're the ones who can explain a decision they made and what they'd do differently now.

Third, get comfortable being wrong in front of people, early and often. The engineers I've watched grow fastest on my teams at Advatix and Apollo were the ones who asked a "dumb" question in a design review instead of nodding along. That habit compounds over a career in a way that raw coding speed doesn't.

Fourth, find people ahead of you who will actually critique your work, not just encourage it. AI assistants are patient and endlessly available, but they don't have context on your career, your gaps, or your blind spots the way a mentor who has watched you work for six months does. Seek that out deliberately — it rarely comes looking for you.

The Opportunity Is Still There

I want to be direct about the part that doesn't get said enough in conversations about AI and entry-level hiring: the field isn't shrinking, it's shifting. Every system I've built or led — warehouse management platforms, telecom fraud protection, healthcare AI — needed more good engineering judgment as it scaled, not less. Companies still need people who can own outcomes, not just produce output. If you're starting out, the honest advice is to spend your early years becoming someone whose judgment a team can rely on. That was true when I started in 2004, and every year since has made it more true, not less.

← Back to all posts