What Teaching Taught Me About Building Technology

I spent five years teaching English in another country and another ten teaching middle school science. Neither job involved software development, but both taught me habits that now shape how I build technology.

Communication is never just about being technically correct

Teaching English in another cultural and linguistic context taught me that communication is never just about the words being technically correct.

You have to understand what the other person is trying to do, what they already know, what assumptions they are bringing with them, and where meaning might be getting lost.

If someone does not understand you, repeating the same explanation more confidently does not solve the problem. You have to change your approach.

You learn to listen for misunderstanding.

You learn to notice when someone is agreeing because they understand and when they are agreeing because they do not know how to say that they are lost.

You learn that the same words can carry different meanings depending on context.

And you learn very quickly not to assume that your own way of explaining something is the natural or obvious one.

That has become deeply relevant to how I think about software and AI.

A system can produce technically correct information and still fail the person using it.

Instructions can be accurate but unusable.

An interface can make perfect sense to the person who designed it and very little sense to the person encountering it for the first time.

An AI system can generate fluent language while misunderstanding the situation underneath it.

So I tend to ask questions that are familiar from teaching:

• What does this person actually need to accomplish?
• What do they already know?
• What might they misunderstand?
• What information do they need now, and what would simply overwhelm them?
• How do we make the next step clear without taking control away from them?

Distinguishing observation from interpretation

Teaching science added another set of habits.

Science education is not just about knowing facts. It is about helping someone understand how we know what we know.

You teach students to distinguish observation from interpretation.

You ask what evidence supports a conclusion.

You test ideas.

You expect some hypotheses to be wrong.

You revise explanations when new evidence appears.

You learn that confidence is not the same thing as accuracy.

Those ideas now show up constantly in the way I think about AI.

I care about whether an output can be traced back to evidence.

I care about distinguishing what a system observed from what it inferred.

I care about whether uncertainty remains visible.

I care about whether a claim can actually be supported.

And I care about designing systems that can say, in effect, “We do not know enough yet,” rather than producing a confident answer simply because the technology is capable of generating one.

Design for the people in front of you

Middle school teaching also taught me something else that matters enormously in software: you have to design for the people who are actually in front of you, not the people you imagined when you wrote the lesson.

A lesson can look perfect on paper and fail completely in a classroom.

Maybe students interpret an instruction differently than you expected.

Maybe something you thought was obvious is not obvious at all.

Maybe one step depends on knowledge they do not have yet.

Maybe the activity technically works, but it creates confusion, embarrassment, exclusion, or unnecessary frustration.

You find out by watching what happens.

Then you change the design.

That is remarkably close to how I now approach software development.

I do not assume that because a workflow works for me, it works for the user.

I test.

I look for failure points.

I watch what happens outside the happy path.

I try to understand why someone made a choice before deciding that the choice was an error.

And I revise the system when reality does not match the assumptions behind the design.

Never blame the learner when the lesson does not work

That becomes especially important when building technology related to domestic violence and survivor safety.

In that context, misunderstanding is not merely inconvenient.

A confusing instruction can lead someone to take an action they did not intend.

A default setting can reveal information.

A notification can expose activity.

A recommendation can sound authoritative even when it does not fit the person's circumstances.

A system that assumes everyone has privacy, control of their device, freedom to act, or the ability to follow a recommended sequence can create risks the developer never intended.

Teaching taught me not to blame the learner when the lesson does not work.

That principle carries directly into how I think about technology.

If a user does something unexpected, I do not want my first question to be, “Why did they use it wrong?”

I want to ask, “What did the system communicate? What did we assume? What did the person reasonably understand from what we gave them?”

That distinction matters even more in survivor-related technology.

People living with coercion, surveillance, limited privacy, financial constraints, or shared technology may use a system in ways that look unusual from the outside but make complete sense within their circumstances.

The software has to make room for that reality.

The responsibility of appearing to know the answer

Teaching also taught me how much responsibility comes with being the person who appears to know the answer.

Students will often trust the teacher because the teacher is standing at the front of the room.

Users can do something similar with software, especially with AI.

A polished interface, confident language, or authoritative tone can make a system seem more certain than it should.

That makes restraint important.

Sometimes the responsible thing is not to provide another answer.

It is to show the evidence.

Explain the limitation.

Ask for more information.

Offer choices.

Or make clear that the person using the system understands their situation better than the system ever could.

From the classroom to code

I came to coding later, but teaching had already trained me in many of the things I now care about most.

• Understand the person before designing the explanation.
• Make complexity understandable without pretending it is simple.
• Separate evidence from interpretation.
• Expect misunderstanding.
• Test assumptions against reality.
• Treat failure as information about the system.
• And never confuse having expertise with having complete knowledge of someone else’s circumstances.

Coding gave me new tools.

Teaching taught me how carefully those tools need to communicate with the people who use them.