How can you tell if you’re a good developer?

First week at mindnow, I walked into a planning meeting and instantly felt outclassed — three people were quoting Erlang papers I hadn’t even heard of. My gut reaction: oh no, they hired the wrong guy. Then the familiar realisation kicked in (happens every couple of years): if the room scares me, I’m probably in the right one. That jolt of discomfort is a decent proxy for growth. Impostor syndrome and improvement travel together; I haven’t found a way to invite one without the other.

The fun part is when even the interns surprise you. We had a junior suggest reversing the order of a data pipeline to cut idle time — significantly reduced idle time on our nightly batch. I’d spent the morning polishing logging middleware instead. Point is, the team’s value isn’t a leaderboard of who writes the fanciest code. The mix — fresh perspectives, scar tissue, weird domain knowledge — is what ships products.

I learned that lesson the hard way on a fintech prototype: codebase spotless, unit tests everywhere, latency through the roof. Meanwhile a scrappy competitor hacked something together in six weeks and took the customer. Messy “it works, ship it” code often beats elegant-but-slow code; you can refactor a hot mess, you can’t invoice latency. (I’m not glorifying spaghetti — just acknowledging trade-offs.)

You mentioned Rust feels overwhelming. Totally normal. I’ve been poking at it for network tooling on and off for a year and still google the borrow checker daily. I recall reading somewhere that rewriting a latency-critical path in Rust doubled throughput after months of side projects. That rang true — fluency shows up later than first results. You were hired because your trajectory looked good, not because you already run `cargo clippy` in your sleep.

So when teammates idly swap unsafe traits in a code review and you’re lost, treat it as reconnaissance. Software is too wide for anyone to hold the full map — what matters is how quickly you build new mental models and how you help others build theirs. I could be wrong, but soft skills like teasing out fuzzy requirements usually compound faster than memorising every `std::sync` primitive.

Your worth isn’t the LOC counter or whatever the “10× engineer” meme claims. It’s the mix of: 1) can you get stakeholders to say what they actually need, 2) can you translate that into something that runs, and 3) can the next person read it without swearing. Raw speed matters, sure, but long-run reputation sticks to those three.

If you feel like the smallest fish, stay put. That tension — “I might drown” — is the same force that forces you to grow gills. Just watch the line between stretch and snap; I missed it once and edged into burnout.

Keep asking questions and, crucially, pin stakeholders down on answers. Vague specs breed late-night rewrites. Senior devs aren’t magical; they’re just relentless about clarity. (I got this wrong for years, thinking velocity was brute keystrokes.)

What makes a “good” developer? My current, imperfect checklist:

1. A real problem lands on your desk — business, scientific, whatever.
2. You figure out what “done” means (often the hidden step).
3. You design a solution that the team can live with — conventions, naming, all that boring trust-building stuff.
4. You deliver, then iterate when new information shows up.

Repeat that cycle most days, and you’re solid. Yes, deeper barometers exist — some companies hand candidates a mini-Git or Redis clone to gauge systems thinking. Fair enough. Just remember: an elegant clone that ignores the project’s style guide can still tank code reviews. Outcomes first, craft second, but neither is optional.

You’re probably further along than your inner critic admits. Keep shipping, keep asking sharper questions, and give Rust (or whatever scares you next) the time it demands.