Retrospective

Starting This Retrospective

I kept records every day.
Decisions from team meetings, technical problems I wrestled with, insights from conversations with teammates, the wins and losses of small feature experiments, and several rounds of trial and error. A lot accumulated.
But I rarely had time to turn it all into one coherent piece of writing.

It is not that I suddenly have more time now. I have just come to feel very clearly that I need a habit of looking back.
Even if records exist, change does not remain clear unless I shape it into sentences.

The Perspective That Changed

For a while, I saw starting a company only as a difficult and risky choice.
Even when I had ideas, I felt that I lacked the ability to realize them, and the fear of failure felt larger.

But the team I met during my internship worked differently.
The engineers on the team were no longer staying only as frontend implementers. They were working as Product Engineers.
Watching that process up close helped me learn how to look at problems more broadly and connect outcomes with value.

A product engineer still writes code, but the perspective is different.
It means moving from someone who creates components and logic to someone who connects the essence of a problem with user response.
That shift changed how I think about startups.

A Growth Routine Built By Experiments

Looking back, the job and startup environment today is clearly different from the past.
Only a few years ago, starting a company felt like a “big decision” for many people.
The requirements seemed enormous: a large team, a lot of capital, and a long preparation period.

Now, thanks to AI and the tooling ecosystem, the initial barrier is lower, and the speed of validating ideas is much faster.
You do not need to prepare everything perfectly.
You can find direction through short experiments and fast feedback.

The job market has also changed visibly.
Instead of simply looking for people who filled out a checklist, teams increasingly look for people who have traces of experimenting and learning on their own.
What remains is not the fact that you failed, but how you handled failure.
More important than success is the quality of learning inside it.

The Way I Learned Through Team Culture

Among the Daangn teammates I met, many had startup experience or at least carried the thought that they would try it someday.
That atmosphere was both stimulating and comforting to me.

A challenge was no longer the domain of extraordinary people.
Small experiments, failed attempts, and changes in direction were all just parts of a working process.

When I meet younger members in my club now, I no longer draw cautious lines the way I used to.
I say “try it” more often than “you must do this.”
The conclusion I reached is simple.

• Attempts do not always have to be perfect.
• But they should not pass by without records.
• What matters is moving what you learned into the next decision.

The Implementation Process I Learned From The Team

The team had many careful and detail-oriented people,
and that became a major standard for my growth.
Even before the internship, I always said the same things to teammates.

• A PR should contain all the thinking behind it.
• A self-review should show why the code was written that way.

I tried to keep that standard, but the team’s actual operating style turned this philosophy into a more realistic process.
The simplest and most important message was this:
feature work should not be a “finish it all at once” task, but a process that becomes routine.

What we needed was ultimately an environment where we could trust each other.
Ideally, more review is not always better.
The better direction is to build trust through review while reducing repetitive work together.

That is why the team emphasized that syncing before writing code is the key.
The sentence I remember most clearly was this:

Before writing code, it should feel the hardest. While writing code, it should feel the easiest.

More concretely, the order was this.
First, clarify the feature spec and agree on it in advance.
Then write a tech spec, check edge cases through implementation details and a user experience checklist.
Once the spec organized the thoughts in my head, writing the code became much more natural.

The PR body is also part of the process.
When it includes the work summary, screenshots, and behavior videos,
reviewers can quickly judge whether the feature behaves correctly,
then focus only on code-level details afterward.

And it does not end there.
We also gave meaning to each line and carried monitoring after deployment as part of the routine.
I saw that this flow was the actual force that raised team productivity.
This experience expanded my standard for “good code” beyond quality alone.
It became a standard of trust that includes the process.

That trust began with routines. Updating Linear as soon as I arrived in the morning was a basic habit.
It may look like a simple work check, but it was a signal that helped teammates trust where my work started and where it ended.
In the end, this was an action that built the social foundation of “being someone others can work with” before code skill.

In that context, one saying from the team resonated strongly with me.

To be good at development, you need to be either extremely F or extremely T.

At first it sounded exaggerated, but the more I heard it, the more the framing made sense.
An extreme F tendency thinks in the direction of reducing teammates’ discomfort.
It considers what kind of readability feels most comfortable, which Slack alerts are too much or too little,
and what information should be included so that non-developer teammates can understand the situation at a glance after deployment.
In practice, I started thinking much more about PR titles.
I tried to write sentences that showed the feature and impact at a glance, and I tried to add the necessary screenshots to deployment notices to fill in context.

An extreme T tendency, on the other hand, focuses on efficiency. It constantly looks for ways to build faster, more accurately, and at lower cost.
What I learned is that these two do not have to collide. They need to complement each other.
The team reset my standard for what “kindness” means,
so my growth was not only at the code level. It was also at the communication level that moves the whole team.

The Standard For Days When I Look Forward To Morning

The rhythm of experiments and speed I mentioned earlier eventually moved into daily life as well.
Whether I am a morning person is no longer the important category.
What matters more is whether I am living a life where I look forward to morning.
That is because I started to feel even a small amount of excitement and desire to take on challenges every day.

Before, development felt like the answer itself.
I would wake up thinking about what problem I would solve tomorrow and what I would improve.
So it was not that I liked mornings. It is more accurate to say that development pulled the starting point of my day earlier.

But that perspective changed again.
For a while, I mistook the intellectual process of digging deeply as an achievement in itself,
so I was more strongly satisfied by the process alone.
What I realized through the internship was different.
Happiness does not come from proving something in my head.
It comes from giving value to teammates in the way I can, and improving something real with the ideas that come to mind each day.
Recognition in those moments finally felt like an achievement that stayed with me.

I still feel that development is fun. The meaning of “why I still like development” has simply changed.
In the past, I had many ideas, but I felt resistance toward AI-assisted development.
Rather than engineering, code felt to me like something that should be completed almost like art.
When I saw AI-generated code, I felt discomfort because I could not control the process, rather than trust.

But the Daangn Alba team moved differently.
It was one of the organizations in Korea using AI most actively, and I learned that culture directly.
One idea the team repeated often was this:
under strict rules, humans should no longer have to type out every line of code by hand.
Set the rules and design first, then change how we think so that AI can write code in the right direction.
I gradually came to agree with that claim.

Now I do not use AI merely as an assistant.
I use it to maximize efficiency in ways others may use less often.
Especially because I am a junior, what I need to handle is not coding tricks,
but the structure of my knowledge that allows AI to respond well.

That is why I feel less often that “there are ideas I cannot realize.”
Challenges became more natural, and I started trying things that once felt far away, like 3D modeling and video work.
Now I understand why I look forward to morning.
It is not because development is fun, but because the process of moving ideas across many areas
makes me excited each morning.