The "Good Job" That Meant the World

If you're a junior developer still figuring out if you're actually good at this or just faking it well — this one's for you. If you're further along, maybe leading a team or managing people — this one's for you too, because someone probably did for you what I'm about to describe. You get to decide if you'll do it for someone else.

A new city, a blank slate, and a project that scared me a little

After years of living out of a suitcase as a traveling consultant, I took a job that finally let me stay in one place. Full-time, in-office, off Exit 3 in Atlanta.

The mission: build a brand-new offer management platform from scratch and retire a legacy system that had been limping along for years. No shortcuts. We sat with outgoing consultants to untangle logic nobody had documented, took in requirements that kept shifting, and built something new out of what felt like nothing.

It was the first time I owned a greenfield application start to finish. I was excited. I was also, if I'm honest, quietly terrified I'd get found out.

The manager who saw me before I saw myself

He wasn't just managing people — he was our lead architect too, and he knew the system down to the bone. But that's not what made him different. What made him different is that he actually looked at me. Not just at my output. At me.

This was before you could spin up a deployment pipeline with one click. We depended on a separate SRE team just to get code onto internal servers, which meant getting product managers, SREs, developers, and business analysts to agree on anything took real patience. He moved through that mess like he'd been born knowing how — and instead of just handling it himself, he brought me in and showed me how.

If you've ever been junior in a room full of people who seem to understand something you don't yet, that's what those months felt like. He never made me feel small for not knowing. He just kept explaining, kept including me, treated my confusion as something to work through rather than something to be embarrassed about.

"Slow down. Let people catch up."

One day at the whiteboard, he pulled me aside and told me something that had nothing to do with the architecture in front of us. "You have great ideas," he said. "But you talk too fast. Slow down. Let people catch up to what you're saying."

I still think about that — not because it was profound, but because of how he said it. Like he wanted me to get better, not like he was annoyed with me. That difference is one junior developers can feel immediately, even when we can't name it. It changed how I show up in every room I've been in since.

Two quiet words

We spent months on that platform. Onboarded new teammates, chased down gaps between departments, and slowly, the thing started to work.

I remember the day we pushed it to the test environment for the first time. The product team logged in, ran the tests, and it worked.

He looked at me and said, "Good job."

That was the whole thing. No applause, no email to the wider org. But if you've ever worked hard for someone whose opinion actually mattered to you, you know two quiet words can outweigh a hundred loud ones. I've collected plenty of praise since that didn't land the way that did.

Why the project's fate didn't matter in the end

The platform never scaled the way we'd hoped — funding shifted, priorities moved on, the way they always do in this industry.

If you're earlier in your career, hear this part clearly: none of that erased what I walked away with. The confidence, the way I lead now, the person I became through building that thing — none of it was tied to whether the project survived. Don't let a project's fate decide whether your growth counted.

What I didn't understand until years later

At the time, I thought I was just having a lucky run with a good boss. I didn't understand yet that a manager who is also a real mentor — someone who'll pull you aside and tell you the useful, slightly uncomfortable thing, who invests in how you think and not just what you deliver — is genuinely rare.

It took years, and a few very different managers who didn't do any of this, before I understood what I'd actually been given. I was blessed to have him, at exactly the point in my career when I needed it most.

If you're a senior developer or manager reading this: you may be someone's version of him right now, and they may not fully understand what you're giving them until years from now. Give it anyway.

The part that had nothing to do with the job

Despite how much I loved the work and the mentorship, there was a quiet ache every day once 5:00 hit. I had a four-year-old at home. Five days a week in the office, pouring myself into a demanding build, meant a lot of evenings where I was still at my desk when I should have been with him. That guilt doesn't announce itself loudly. It just sits there, in the background, every day.

Leaving wasn't a simple decision. But I learned something in that chapter that I still carry: career growth isn't only about moving faster. Sometimes it's about choosing what fits the season of life you're in. I eventually moved to an individual contributor role closer to home — a different chapter, with its own lessons about autonomy, for another post.

What AI still can't touch

The tech has changed completely since that Atlanta chapter. The lesson hasn't moved an inch.

Ask an LLM to scaffold a Spring Boot service for offer management and you'll have boilerplate in seconds. What it can't do is notice you're nervous before a presentation and pull you aside afterward. It can't sit beside you through a messy negotiation with an SRE team and show you how to hold your ground without burning a bridge. And it can't look at something you built with your own hands and say "good job" in a way that actually reaches you.

Code will keep getting easier to write. What made that Atlanta chapter matter wasn't the code — it was a person who cared enough to slow down and teach me things that had nothing to do with syntax.

If you're early in your career: keep an eye out for that person. If you're further along: consider being that person for someone else. You may not know how much it mattered until years after you've said it.

What's the best non-technical advice a mentor ever gave you? I'd genuinely like to hear it in the comments.