Twenty Years in Software: What I Actually Learned

I took a non-traditional path into software engineering: no CS degree, no bootcamp, no formal training (I had a degree in 3D animation and videography). I learned by breaking things and figuring out how to fix them — and I've been doing that for twenty years now.

I've been an individual contributor, a lead, a manager, and most things in between. I've worked at startups where the "team" was two people, a sun room, and a shared sense of denial, and at enterprises where getting a new tool approved took longer than building it. I've shipped many things I'm proud of, and many more things I'd rather not mention.

SO! What actually stuck?

The Technical Stuff Is Seldom the Hard Part

I spent a large part of my early years believing that if I just got good enough at the craft — the code, the architecture, the systems — everything else would sort itself out.

Turns out, though, that the hard part is almost always people. Communication. Alignment. The gap between what someone said in the meeting and what they actually meant. The thing nobody raised in standup that eventually became an "oh shit, everything is on fire" incident.

Technical skills can be taught relatively quickly. A motivated engineer can become functional in a new language in weeks if they are adaptable. What's genuinely hard to teach is the ability to adapt and interpersonal skills. It was a hard lesson I didn't learn till I stumbled my way into management. Looking back, I now understand the struggle my manager dealt with trying to get me to communicate effectively instead of just thinking about all problems from a coding perspective.

When I'm evaluating people now, I care far more about how someone thinks and how they work with others than I do about which specific technologies they know. The technical gaps are almost always fillable. The other stuff is harder to move.

Nobody Knows What They're Doing as Much as They Appear To

Impostor syndrome is close to universal in this field, and it doesn't fully go away at any level. Senior engineers feel it, Directors feel it, and even CTOs feel it. Honestly, I am more worried if someone talks about how they don't suffer from it. Or if they are constantly going on about how good they are (I've only ever dealt with that the one time).

What generally separates a senior from a junior isn't that the senior always knows the answer — it's that they have enough background to know what to look for. They've seen similar problems before. They know which questions to ask. They know when something smells wrong even if they can't immediately name why. They also usually know the best question to ask Google, or well, I guess Claude now.

What changes over time is that you get comfortable operating in uncertainty. You learn to say "I don't know" out loud without it feeling like an admission of failure. That comfort is one of the most useful things you can develop. It makes you more trustworthy, not less.

The Half-Life of Technical Knowledge Is Shorter Than You Think

In twenty years I've watched entire stacks go from cutting-edge to legacy in a lot shorter time frames than you would think. Frameworks rise and quietly disappear. The thing your team just spent six months mastering is sometimes the thing you're migrating away from in three years or less. I'm looking at you Angular…

Being self-taught actually gave me an edge here, though I didn't realize it at the time. I never had the luxury of going deep on one language or framework in a formal program. I had one class in HTML 4.01 Transitional. I had to pick things up as I needed them — and that forced me to develop a set of general concepts and patterns that transfer across languages. I can sit down with something I've never used before and become functional with it fairly shortly because the underlying ideas are the same. That's how I've gotten to where I am.

The engineers who last — and stay relevant — are the ones more attached to learning than to any specific technology. Adaptability compounds in a way that any specific skill never will. We are seeing this even more now with the AI boom. If engineers don't adapt, they will eventually be replaced. It doesn't have to be that way. All they have to do is learn to make AI work for them.

Your Reputation Is Built on Small Things

Not the big launches. Not the flashy projects.

Your reputation is built on whether you follow through on what you said you'd do. Whether you treat fellow engineers with the same respect as the people above you. Whether you give credit where it's due. Whether you show up when it matters — not just when it's convenient. Let's face it, the bare minimum will get you replaced. I know, I know that sounds harsh, but it's true. In a field that moves as fast as this one, coasting is a slow exit. The people who stand out over a long career are the ones who consistently go beyond what's asked — not because someone told them to, but because they give a damn.

People are paying attention even when you think they're not. Reputations are built slowly and damaged quickly.

I've been on teams with world-class talent that were miserable to work with. I've been on teams with less experienced people who shipped good, solid code and useful features. Most importantly, we genuinely enjoyed doing it, and we had fun.

The difference, every time, was psychological safety.

On the good teams, people could raise concerns without bracing for impact. Junior engineers could ask questions without feeling stupid or annoying. Disagreements happened in the open instead of in DMs after the meeting. Ideas from unexpected places got taken seriously.

Trust and constant communication are a necessity. Everything else is downstream of it. You can have the best engineers in the world, but if they're afraid to speak up or disagree, you're not getting anywhere close to what they're actually capable of.

Mentorship Goes Both Ways

I learn from my engineers on a daily basis. That's not a humble brag — it's just reality.

I'm not in the code every day. My engineers are way better engineers than I am, and that's exactly how it should be. The reason I'm in the role I'm in is that I chose the more business-facing side of the work. I'm not competing with them technically. My job is to teach process, share concepts, remove obstacles, and then get out of the way and let them fill in the gaps.

The best mentors I've had were also willing to be taught. They stayed curious. They didn't treat experience as a reason to stop listening. I try to operate the same way. If you can't learn from the people you're leading, you're not paying attention.

Stay humble. Stay teachable. The day you think you have nothing left to learn from someone junior to you is the day you start going backward.

Burnout Is Real and the Industry Doesn't Talk About It Honestly

This one I feel strongly about.

Burnout is the death knell for a lot of engineers over a long career. How many senior engineers have you heard say they want to disappear into the woods and never look at a screen again? I've heard it more times than I can count — and some of them actually did it. I contemplate it at least weekly. Talented people have gone from the field entirely because the industry ran them into the ground, and nobody talked about it until it was too late.

The "always on" culture, the endless on-call rotations, the startup pressure to sacrifice everything at the altar of velocity — it catches up with people. And the signs are usually there long before anyone acknowledges them. Running on empty. Producing less while working more. Dreading Monday in a way that used to feel foreign.

If that sounds familiar: pay attention to it. It doesn't fix itself. BUT wait! I just said earlier that the bare minimum is not good enough. I stand by that, but that doesn't mean that burnout should be the norm. Show up when it counts, but don't make the job your life.

Take the PTO. Set the boundary. Close the laptop at the end of the day sometimes. The code will still be there, and if it won't be, that's a different problem worth solving.

Twenty years in, I'm still learning. Still wrong sometimes. Still occasionally in over my head in something new.

What's changed is that I've made peace with all of it. That's not resignation — it's just what a long career in software actually looks like. The problems keep getting more interesting. The people, the good ones, are some of the best you'll ever work alongside.

If you're earlier in the journey and reading this: get comfortable being uncomfortable. That feeling never fully goes away. Learning to work with it, rather than waiting for it to stop, is half the job.