Prosocial Coding
Human systems

What Anthropology Taught Me About Building Technology

My anthropology degree turned out to be surprisingly good preparation for building software.

6 MIN READRyan Thomas
Illustration of Bigfoot wearing glasses and working on a laptop atop a mountain summit at sunset
Fieldwork meets software architecture: examining human systems from unexpected vantage points.

Not because anthropology taught me how to write code. It taught me something that I now think matters just as much: how to look at a system from the perspective of the people who have to live inside it.

Anthropology trained me to pay attention to context. To question assumptions. To notice how power operates. To understand that people do not encounter institutions, policies, or technologies under identical circumstances.

Years later, when I began learning to code, those habits followed me into the work.

The question before the technical question

Software development naturally encourages certain questions.

Can we build it? Does it work? Is it fast? Is the interface intuitive? Can we automate this?

Those are important questions. But they are rarely the first questions I want to ask.

I want to know:

Who is using this?

Under what circumstances?

Who else might have access?

What assumptions are we making about the user's household, devices, relationships, knowledge, or freedom to make choices?

What happens when those assumptions are wrong?

And what could this system make possible for someone other than its intended user?

Those questions become especially important when technology intersects with domestic violence and survivor safety.

A notification can be useful in one context and dangerous in another. A shared account can be convenient or a mechanism of surveillance. Location information can provide assistance or reveal someone's movements. A record intended to document something important can create risk if someone else gains access to it.

The technical behavior of the feature has not changed.

The human context has.

Software is part of a human system

One of the most useful things anthropology taught me is that tools cannot be understood separately from the systems in which people use them.

Software is no exception.

An application exists alongside relationships, institutions, policies, devices, accounts, economic constraints, social expectations, and power.

That changes how I think about safety.

Safety cannot simply be a feature added near the end of development. It has to be considered across the system.

Who controls the account?

Where does the data go?

How long does it remain there?

What appears in notifications, browser history, email, backups, logs, or shared devices?

Can someone safely leave?

Can someone make a mistake without creating disproportionate consequences?

Can the system distinguish what it knows from what it has inferred?

These are technical questions, but they are also questions about people and power.

Survivor-centered design changes the engineering questions

My work in the domestic violence movement sharpened this perspective considerably.

Survivor-centered practice asks us to respect autonomy, recognize that survivors are experts in their own circumstances, and avoid substituting institutional assumptions for lived experience.

Applied to technology, that principle changes the design process.

Instead of asking only whether a feature helps a survivor, I also ask whether it could increase another person's ability to monitor, constrain, expose, or retaliate against them.

Instead of assuming privacy because information is behind a login, I ask who might know the password, control the email account, share the device, receive the notification, or have access to a backup.

Instead of assuming there is one correct action, I think about whether the technology preserves meaningful choices.

That is not pessimism about technology.

It is taking technology seriously enough to consider how it behaves outside the ideal use case.

Anthropology also changed how I think about AI

AI makes these questions even more important.

An AI system can produce an answer that sounds confident even when the underlying evidence is incomplete. It can flatten complicated circumstances into categories. It can mistake correlation for meaning. It can present an interpretation as though it were an observation.

That makes provenance, uncertainty, evidence, and human judgment central design concerns.

When I build or evaluate AI systems, I want to know:

What evidence supports this output?

What is observation and what is inference?

What information is missing?

What assumptions are embedded in the prompt, model, rubric, or evaluation method?

How is uncertainty communicated?

When should the system defer to a person?

And what happens if the system is wrong?

These questions sound technical in an AI application. But the habit behind them is familiar.

Observe carefully. Understand context. Question your categories. Examine your own assumptions. Pay attention to power. Do not confuse your interpretation of another person's experience with the experience itself.

That is anthropology.


From anthropology to code

I sometimes describe myself as someone who learned to code later.

That is true, but it leaves out an important part of the story.

I did not arrive at software development empty-handed.

Anthropology gave me a way of seeing human systems. Teaching strengthened my ability to explain complicated ideas and design for learning. Domestic violence work taught me about survivor autonomy, coercive control, safety, and the consequences of systems that fail to account for lived reality. Grant and organizational systems work taught me how policies, funding, operations, data, and technology interact.

Coding gave me another implementation tool.

It allowed me to take ideas that previously might have become a recommendation, training, workflow, or proposal and turn some of them into working software.

That combination now shapes how I approach Prosocial Coding.


Build from the human system outward

I am interested in what technology can do.

I am equally interested in what it assumes.

Who does the system imagine its user to be? What circumstances does the happy path assume? Whose definition of success has been encoded? What happens at the edges? Who bears the consequences when something goes wrong?

Those questions do not replace good engineering.

They make the engineering better.

I learned to code so I could build things.

Anthropology taught me to question what should be built, for whom, under whose assumptions, and with what consequences.

I bring both to the work.