Women in tech · 5 min read · Sep 19, 2026
I learned faster when I stopped trying to sound technical
When I arrived at Concordia, I had zero coding experience.
I wasn’t following a carefully planned path into technology. I was studying economics, asking questions about behaviour and markets, and eventually realizing that the questions I wanted to answer required skills I didn’t yet have.
So I started learning.
At first, I thought becoming technical meant collecting enough vocabulary to follow the conversation: joins, APIs, containers, orchestration, streaming, schemas.
Recognizing the words felt like progress. Sometimes it was. But recognition can also create a dangerous illusion: I know what that term means, so I must understand how it works.
The moments when I learned most were usually the ones when I stopped trying to sound informed and admitted exactly where my mental model ended.
“I understand it” is too large a claim
Take a LEFT JOIN.
The familiar explanation is:
A left join keeps every row from the left table.
That is correct—but incomplete.
Suppose the left table has one customer row and the right table has five orders for that customer. The join does not preserve one customer row. It returns five rows because the customer matched five orders.
Now the better questions appear:
- What does one row represent before the join?
- What does one row represent after it?
- Is the relationship one-to-one, one-to-many or many-to-many?
- Which metrics will be multiplied?
- Should the right table be aggregated first?
Knowing the definition helped me recognize the operation. Finding where the definition broke helped me understand it.
That became a useful learning rule:
Don’t ask whether you understand a concept. Ask whether you can predict its behaviour.
The confusion ledger
Turn a vague gap into something testable.
Keep a confusion ledger
When I am learning something technical, I find it useful to separate four things:
| Field | Example |
|---|---|
| What I heard | “Streaming processes data in real time.” |
| My current model | Events are processed individually as they arrive. |
| Where the model feels incomplete | Does every event really appear immediately? What happens if it arrives late? |
| A testable question | How would the result change if an event arrived ten minutes out of order? |
Calling it a ledger matters.
A vague feeling of confusion is difficult to work with. A named gap can be researched, tested or taken to someone who knows more.
It also changes the emotional meaning of not knowing. The gap is no longer evidence that I am “not technical.” It is simply the next unresolved item.
A useful AI workflow
Use AI as a patient rehearsal partner
AI can be helpful here because it does not get tired of follow-up questions.
But “Explain Kafka to me” often produces a smooth overview that is easy to read and easy to forget.
A better prompt forces the explanation to reveal its boundaries:
Teach me [concept] in five stages:
- Explain it in plain language without an analogy.
- Show one concrete example using no more than five records or components.
- State the simplified rule beginners usually learn.
- Give me a case where that rule becomes incomplete or misleading.
- Ask me to predict the result of a new example before revealing the answer.
After I respond, identify the exact part of my mental model that is wrong or incomplete. Do not praise the answer unless the reasoning is correct. List any assumptions you cannot verify.
The final instruction is important. AI assistants are often optimized to keep a conversation encouraging. Encouragement is pleasant, but agreement is not the same as correction.
I want the model to show me where my reasoning fails—not congratulate me for using the right vocabulary.
Make the explanation survive contact with reality
An AI explanation is still only a hypothesis until it matches observable behaviour.
For code, create the smallest possible example and run it.
For a data concept, write five rows by hand and calculate the expected result before executing the query.
For an architecture decision, change one condition:
- What if traffic increases tenfold?
- What if messages arrive out of order?
- What if the downstream service is unavailable?
- What if the same request is retried?
- What if a user is not allowed to access the underlying record?
Then compare the explanation with primary documentation and the actual output.
This matters because AI can give a clear explanation of the wrong version, omit an important condition or confidently describe behaviour from an older release.
Clarity is useful. Execution is evidence.
Technical confidence is not instant recall
I used to think technical confidence meant being able to answer immediately.
Now I think it looks more like this:
- identifying the layer where the problem lives;
- stating what you know and what you are assuming;
- reducing a large question to a small test;
- noticing when the result contradicts your model;
- and updating the model without defending the old one.
That approach scales beyond coding.
It works when defining a metric, diagnosing a pipeline, evaluating an experiment or understanding an AI system. The specific technology changes. The habit of making uncertainty visible remains useful.
Try this
Choose one technical term you used this week.
Without searching, write:
- What it does in one sentence.
- One concrete example.
- One condition where your sentence stops being sufficient.
- One test that could prove your explanation wrong.
Then give your answer to an AI assistant using this instruction:
Critique my mental model. Identify missing conditions, incorrect assumptions and ambiguous language. Give me one counterexample. Do not rewrite the explanation until you have shown me what is wrong with it.
Finally, verify the most important correction by running an example or checking the primary documentation.
You do not need to understand everything before you belong in a technical conversation.
But you do need to be honest about what you understand today—and curious enough to find the next edge of it.
That is how I taught myself in the beginning.
It is still how I learn now.