I graduated college in May 2016 and walked straight into my first tech job in the defense industry. I was 22, I had no idea what I was doing, and I was writing Java for the government. Since then I’ve switched industries, survived layoffs, led projects, been a cog in the machine, and watched the entire landscape of software development change underneath my feet more than once.
Ten years goes fast. Here’s what actually stuck.
Remote Work Is a Superpower. If You Treat It Like One.
Remote work gets a bad reputation because most people do it wrong.
The flexibility is real. The productivity gains are real. But none of it matters if you treat remote work like an excuse to become invisible. The engineers who thrive working remotely are the ones who work harder at staying connected than they ever did in an office.
That means scheduling the optional coffee chats. Over-communicating on Slack. Showing up to the all-hands with your camera on. Building real relationships with people you’ve never met in person. It sounds exhausting because it is, but it’s the price of admission. Remote work rewards the intentional. It punishes the ones who just want to disappear.
If you’re putting in that effort, remote work is genuinely hard to beat.
Layoffs Are Rarely Surprises
I’ve been through layoffs. They’re awful. But I’ll tell you something that took me too long to figure out: most of the time, you can see them coming.
The biggest tell is how the company talks about its people. Organizations that refer to employees as “resources” in meetings, in planning docs, in all-hands slides are the ones the watch out for. Those companies have already made the mental leap to treating you like a line item instead of a human being. When the spreadsheet needs to balance, line items get cut.
There are things you can do to protect yourself. First, get visible. Your manager knowing your name is not enough. You want directors knowing your name. VPs knowing your name. The more people who can advocate for you when the list is being made, the better. Second, work on things that directly affect the company’s bottom line. Internal tools are nice. Revenue-driving features keep you employed. Third, if you have the choice, work directly for the company rather than as a contractor. When cuts come, contractors are almost always first.
None of this is a guarantee. But it shifts the odds.
The Tech You Know Today Is Already Aging
I started my career writing jQuery. By the time I left my second job, React had taken over. On-prem servers became AWS. Monolithic backends became microservices. The patterns and tools I thought were permanent were replaced, sometimes more than once, inside a single decade.
AI is not different. It’s the current wave. The engineers who are treating it like a distraction or a fad are making the same mistake developers made when mobile became the dominant platform and some teams were still designing desktop-first. Adapt or get left behind. That’s always been the job.
The good news: it has never been easier to learn. A Udemy course, a YouTube deep dive, a weekend project. There’s no excuse anymore for not keeping up. The resources exist. The only question is whether you’re using them.
Your Value Isn’t Your Code. It’s Your Judgment.
This one took me a while to really understand.
Junior engineers think the job is writing code. It’s not. The job is solving problems. The code is just the output. What actually makes a great engineer is the ability to look at a system, understand its constraints, and design something that holds up over time. That comes from learning patterns. Learning algorithms. Learning when to reach for the simple solution and when the complex one is actually worth it.
The engineer who can write elegant code but can’t explain why they made the architectural decisions they made is fragile. They’re only useful in one context. The engineer who understands systems can pick up any language, any framework, any stack, and still deliver. That’s the person you want to be.
Learn the fundamentals. Obsess over design patterns. Read about systems at scale even when it’s not immediately relevant to your work. It compounds.
Most Engineers Can’t Communicate. Be the One Who Can.
I’ve worked with brilliant engineers who were completely useless in a stakeholder meeting. Not because they didn’t know their stuff. Because they couldn’t explain it.
Technical communication is a skill, and most people in tech treat it like a second-class citizen. Writing documentation nobody reads. Giving status updates that make non-technical people’s eyes glaze over. Assuming that if the code works, the explanation doesn’t matter.
It matters enormously. The engineers who grow the fastest are almost always the ones who can write clearly, present confidently, and translate what’s happening in the codebase into language that a product manager or an executive can actually act on. It’s not a soft skill. It’s a force multiplier. Every other skill you have gets bigger when people can actually understand you.
Write more. Document more. Volunteer to present the technical work to the business. You’ll be uncomfortable at first. Do it anyway.
Know Whether You’re Leading or Contributing (and Why)
For most of my career I’ve chased leading projects over being a pure individual contributor. I prefer it. The ownership feels different when you’re steering the thing, not just building a piece of it.
But it comes with a cost. Leading is more stressful. You’re accountable for more. When something goes sideways, it’s on you in a way that it isn’t when you’re an IC.
Being an individual contributor has real advantages. Less stress. More focus. You can go deep on a problem without worrying about the twelve other things the project needs. But here’s what I’ve noticed: the ICs who stagnate are the ones who never own anything. They do their tickets, they do them well, and then they disappear. The ICs who grow are the ones who become the go-to person for something. The caching expert. The person who knows the payment integration cold. The one everyone pings when the build pipeline breaks. That ownership, even without a formal leadership title, is what gets you recognized and what gets you better work.
Neither path is wrong. Just know which one you’re on and be intentional about it.
Burnout Is Real. Don’t Wait Until You’re Empty.
Tech burnout is not a myth. It’s not a sign of weakness. It’s what happens when you spend 18 months on the same project, with the same problems, in the same meetings, and nobody asks whether you want to be there anymore.
The mistake most people make is waiting too long to say something. They grind through it, tell themselves it’s normal, and then one day they’re completely checked out and it takes months to recover.
Speak up earlier than feels comfortable. Tell your manager you need something new to sink your teeth into. Ask to rotate onto a different project. If the company won’t give you any runway for that kind of change, start looking. A new job is not failure. Sometimes it’s the only thing that actually resets the clock.
Build Something for Yourself
Somewhere in between the day job and everything else, build something that you actually find useful.
Not a tutorial clone. Not a resume project designed to impress a hiring manager. Something you would actually use. Ship it. Put it on the internet. Let it exist.
It’ll teach you things that professional work doesn’t. You’ll make every decision yourself. You’ll deal with the full stack of a product, from the idea to the deployment to the weird edge cases you didn’t anticipate. And when it actually solves a problem you had, that feeling is genuinely different from any ticket you’ll ever close at work.
It doesn’t have to be big. It doesn’t have to be profitable. It just has to be real.
The Industry Changes. You Have To Change With It.
Software development in 2026 looks almost nothing like it did in 2016. The tools are different. The patterns are different. The expectations are different. What made someone a great engineer ten years ago is not a complete picture of what makes someone great today.
The engineers I’ve watched have long, successful careers aren’t necessarily the smartest people I’ve worked with. They’re the most adaptable. They’re curious without being anxious. They learn the new thing without throwing away everything they already know. They treat change as part of the job, not a threat to it.
That’s the actual skill. Everything else is just the current expression of it.
Ten years is long enough to have made real mistakes and short enough that I’m still making new ones. I don’t have this figured out. I just have more data than I used to. The honest truth is most of this stuff I learned the hard way. You don’t have to. That’s why I wrote it down.