What Three Years in Software Actually Taught Me

I was three years old the first time I sat in front of my parents’ IBM Windows 95 machine. I didn’t understand what I was looking at — I just knew someone had built this world, and I wanted to be that person. Three years ago I walked in as a junior engineer. This week I was awarded Senior Software Engineer. Here’s what I’d pass on.

Find the people who will shape how you think

This is the part most career posts skip, and it’s the part that mattered most.

Early on, I got to work closely with thoughtbot consultants — one of the most respected software consultancies in the Rails world, known for setting the standard on engineering craft. Each one had deep domain knowledge and a distinct way of thinking about software. I sought every opportunity to work with them: pairing on problems, having conversations that stretched how I thought about code.

They didn’t just teach me Rails. They shaped the craft — clean code, test-driven development, thoughtful abstractions. That worldview carried into everything I built after.

Here’s what I want every junior engineer to hear: find the people who are willing to take you under their wing. They exist. Every senior engineer was a junior once. Seek out mentors — not because you’re weak, but because learning from people who’ve been where you are is the fastest way to grow.

And ask questions. Don’t be afraid to say “I don’t get it yet.” Five words that will accelerate your growth faster than any tutorial. Someone is always willing to help — but they can’t help if you pretend you already understand.

Go beyond your lane — on purpose

The engineers who grow fastest aren’t the ones who go deep in one thing forever. They’re the ones who know when to go wide.

I was hired as an iOS engineer. I learned Rails because I wanted to understand the full picture, not just my corner of it. And it paid off immediately — once I understood the backend, I finally understood the why behind every API I was consuming as an iOS engineer. The full picture changes how you build your corner of it. I got uncomfortable with Android. I gave a talk on prompt engineering at an All Hands. None of that was on a roadmap. All of it made me sharper.

Eventually going beyond my lane meant going beyond my job entirely. While still at CloseKnit I started doing independent AI consulting — building RAG platforms, autonomous agents, and vision pipelines from scratch for a contractor marketplace. A completely different domain, a completely different stack. Turns out the lane doesn’t matter as much as the driver.

If you only know your layer, you can only solve your layer’s problems.

Take initiative before someone hands it to you

A coworker told me early on: don’t just find work that needs to be done — find work that needs you to get done. Guillermo del Toro said something similar: “You need to choose projects that need you to exist — if you don’t make them, nobody will.”

That stuck. The best things I shipped weren’t assigned to me. I saw gaps, found the right tools, and moved. Nobody asked me to build an internal AI chatbot or give a company-wide prompt engineering talk or formalize Copilot standards across the repo. I saw opportunities to make the team better and I went after them.

Initiative isn’t just about working hard. It’s about making yourself the person who moves things forward before anyone thinks to ask.

Use AI — but own your understanding

AI grew massively over the course of my career. It became genuinely useful. But I want to be careful here, especially for junior engineers: AI is a tool, not a teacher you follow blindly.

AI is a force multiplier — it makes you faster, broader, more capable. But a multiplier amplifies what you bring to it. Bring critical thinking, and you get a sharper engineer. Outsource the thinking entirely, and the multiplier starts working against you.

There’s a line from the Chernobyl miniseries that I keep coming back to: “Every lie we tell incurs a debt to the truth. Sooner or later, that debt is paid.” I think about it every time I use an LLM. Every query where you accept the output without questioning it is a small withdrawal from your own thinking. The debt is quiet at first. Then one day you realize you’ve stopped knowing why things work — you just know the model said so.

Use it to learn. Use it to move faster. But question its output. Ask it to explain itself. Verify what it tells you. Sometimes you arrive at the same conclusion — but you arrived there through understanding, not blind trust. That difference is everything. And sometimes the right call is putting it down entirely. Knowing when the tool is the wrong choice — that’s the senior move.

What I’d pass on

1. Find your mentors. Be humble enough to learn from them. Ask the dumb questions.
2. Go beyond your lane. If you only know your layer, you can only solve your layer’s problems.
3. Take initiative. Find the work that needs you to exist — then ship it.
4. Get uncomfortable regularly. Rails was uncomfortable. Android was uncomfortable. Giving a talk at All Hands was uncomfortable. Every time, I came out better.
5. Use AI, but own your understanding. The tool is powerful. Your critical thinking is more powerful.
6. Ship early, ship often. Perfection is procrastination with a nicer name.

The thing that stuck with me most

My people leader told me early on: every time you touch the code, leave things a little better than when you found them.

I’ve thought about that a lot over three years. It’s advice about code hygiene on the surface — but it’s really about how you show up. Leave the codebase better. Leave the team better. Leave the people around you better than you found them.

Three years in, I’m not the same engineer who walked in the door. The three-year-old in front of that IBM wouldn’t recognize the tools — but he’d recognize the obsession. And I’m not done yet.