About a year ago, a colleague joined the team I was working on. While introducing himself, he said something that caught me completely off guard.
“I’m really good at TypeScript.”
It wasn’t arrogant or boastful. It was simply a statement of fact. What surprised me wasn’t what he said, it was my reaction.
I remember thinking, I’m really good at TypeScript too.
And then, almost immediately, another thought followed, Wait… am I allowed to say that?
For most of my life, I’d associated people claiming they were good at something with arrogance. I’d met enough people who overestimated their abilities that I had unconsciously decided the safest option was never to make those kinds of claims about myself.
Looking back, I think I overcorrected.
Saying you’re really good at something isn’t the same as saying you’re the best. It isn’t a comparison with everyone else. It’s simply recognizing a strength that you believe you’ve developed.
That conversation gave me permission to think differently.
The harder question, though, is:
How do you know what you’re really good at?
Looking for evidence instead of intuition
Before I ever started using LLMs, I was already trying to answer that question.
When I was preparing for my promotion from Senior Software Consultant to Staff Software Consultant at Test Double, I didn’t sit down and try to convince myself I was ready. Instead, I asked the people around me for written feedback on what it was like to work with me.
I asked clients, colleagues, and managers.
I asked the people whose opinions I respected the most.
I also made a point of asking the people who intimidated me the most. I was convinced they would tell me I wasn’t contributing enough. That they would see through me and confirm my insecurities: I thought they’d point out that I wasn’t writing enough code, solving enough difficult technical problems, or making a large enough visible impact.
Instead, one of them gave me one of the strongest endorsements I’d ever received. He talked about my ability to ask good questions, create clarity, and help teams find alignment. Those weren’t the things I would have listed about myself.
I gathered all of that feedback into my promotion document and rather than telling people why I deserved the promotion, I simply said:
“Don’t take my word for it. Here’s what the people I work with consistently say.”
It became much less about self-belief and much more about evidence.
AI didn’t invent this. It changed the scale.
Today I use LLMs to do something remarkably similar.
I’ll give Gemini a meeting transcript and ask:
Where did I create the most value?
I’ll feed ChatGPT performance reviews and peer feedback and ask:
What patterns keep showing up?
I’ve pointed Cursor at an entire codebase and asked it to analyze every commit I’ve made.
What kinds of problems do I naturally solve?
What themes emerge across my work?
What kind of engineer am I when you look at years of contributions instead of individual commits?
I’ve even used AI as a sounding board to talk through difficult situations, asking it to notice recurring themes in how I think about problems.
I don’t ask AI to tell me who I am. I ask it to synthesize far more evidence than I could ever hold in my head at once, and it helps me see emergent patterns that were always there.
The hidden variable: effort
As I’ve done more of this, one pattern keeps appearing: The things that require the most effort from me often aren’t the things people value most. I’ve spent enormous energy on work that I thought was important because it was difficult. Sometimes it received very little recognition. Other times, the things people appreciated most were the things that felt almost effortless. That realization changed how I think about strengths.
We often assume that if something feels difficult, it must be valuable. But difficulty is an internal experience, while value is an external observation.
I’ve had periods where I tried to maximize my availability because I thought that was the most helpful thing I could do. The result was that I had less uninterrupted time for the kind of thinking that actually created value.
I’ve owned responsibilities simply because I was capable of doing them, only to realize that someone else on the team could do them just as well, or even better, while I focused on work that came more naturally to me. Instead of doing things just because I’m capable, now I ask myself:
What does this cost me?
And what could I be doing instead?
Maybe you’re looking in the wrong place
When we think about strengths, we often think about technologies or job titles.
Are you good at TypeScript? React? Architecture? Databases?
But the more durable strengths are often much harder to see:
Maybe you’re unusually good at simplifying complexity.
Maybe you’re the person who creates alignment when a team is stuck.
Maybe you ask the question that changes the direction of an entire meeting.
Maybe you learn unfamiliar things quickly.
Maybe you consistently reduce complexity instead of adding to it.
These are all ways of thinking. If you’ve always thought a certain way, it may feel completely ordinary to you.
What feels easy?
One of the most useful questions I’ve started asking myself is this:
What valuable things feel disproportionately easy to me compared with how hard they seem for other people?
Not everything that’s easy is valuable. Some things are easy because they’re trivial. But occasionally you’ll find something that other people consistently describe as difficult or valuable, yet it feels almost natural to you. Those are worth paying attention to.
Ironically, they’re also the strengths you’re most likely to overlook because they don’t feel exceptional, they just feel normal.
Stop using effort as evidence
Reflecting on your own work, asking people for feedback, and looking for patterns in your contributions aren’t new strategies.
What’s new is that tools exist that can aggregate and synthesize years of conversations, code, documents, and feedback in minutes to reveal patterns you would never be able to hold in your head at once.
Gathering evidence and feeding it into an LLM helps surface those patterns more clearly, especially across long spans of work where memory and intuition start to blur.
I assumed that the things that took the most effort were the things that mattered most. I discovered the opposite was often true: the work that exhausted me was simply difficult for me, while the work that people consistently valued was the work that felt natural.
James Walker is a Staff Software Consultant at Test Double, and has experience in software architecture, technical leadership, team alignment, product strategy, and AI-assisted development.
