This is part 3 of a series on reading backend code. Start from part 1.
When I first looked at real backend code, it felt impossible to read.
Something like this:
await prisma.session.update({
where: { id: sessionId },
data: { status: "paused", pauses },
})looked like alien language.
Too many braces. Too many dots. Too many nested things.
But after slowing down and reading enough code, I realized something important:
Most backend code is actually built from just 4 ideas:
- Action
- Data
- Condition
- Result
Once I started seeing code this way, everything became easier to read.
1. Action
An action is simply: "Do something."
Usually this is a function call.
pauseSession()or:
prisma.task.update()These are actions. They tell the program to perform work.
Real example
await prisma.task.update({
where: { id: taskId },
data: { status: "active" },
})The action is update(). Everything else is just information for the action.
2. Data
Data is the information we pass around. Usually it looks like objects:
{
status: "active"
}or arrays:
;["apple", "banana"]Backend code passes data everywhere.
Example
data: {
status: "paused"
}This just means: here is the data to save.
Important realization
Most scary-looking backend code is actually just nested data.
{
where: {
id: sessionId
},
data: {
status: "paused"
}
}This is just an object inside another object. Nothing magical.
3. Condition
Conditions control decisions.
if (lastPause && !lastPause.end)At first this looks confusing. But in English it means:
If lastPause exists AND it does not have an end time.
That's all.
Most backend logic is conditions
if (user)if (!token)if (session.status === "paused")These are just decisions.
4. Result
Every action usually produces a result.
const session = await prisma.session.findUnique(...)The result is stored in session.
So the flow becomes:
- Do action
- Get result
- Use result
The big shift in understanding
Beginners often try to read code symbol by symbol. Like this:
- what does this brace mean
- what does this dot mean
- what does this parenthesis mean
Experienced developers don't read code that way. They chunk it into meaning.
await prisma.session.update(...)instantly becomes: "database update"
And:
if (!user)becomes: "check if user exists"
That pattern recognition is what makes code feel readable.
The real problem isn't syntax
Most of the time, the syntax itself is simple. The real difficulty is nested structures.
await prisma.session.update({
where: { id: sessionId },
data: { status: "paused", pauses },
})This combines:
- function call
- object
- nested object
- variable shorthand
- async waiting
all at once.
That's why it feels overwhelming.
A trick that helps
Take complicated code and rewrite it in smaller pieces.
Instead of:
return prisma.session.update({
where: { id: sessionId },
data: { status: "running", pauses },
})rewrite mentally as:
const whereData = {
id: sessionId,
}
const updateData = {
status: "running",
pauses: pauses,
}
return prisma.session.update({
where: whereData,
data: updateData,
})Now the structure becomes obvious.
Backend code is repetition
After enough exposure, you realize most backend apps repeat the same patterns forever:
- Receive data
- Check condition
- Perform action
- Return result
That's basically the entire architecture of many APIs.
Final thought
The moment code became less scary for me was when I stopped seeing giant blocks of syntax and started seeing:
- Action
- Data
- Condition
- Result
Once you recognize those four things, most backend code becomes much easier to follow.