A personal retrospective on the Boostcamp Web·Mobile Challenge phase: daily missions, CS learning, peer feedback, teamwork, and how I learned to grow alongside AI
The password you enter is used to open, edit, and delete secret comments.
No comments yet.
The Challenge is structured as a combination of CS‑focused learning and daily missions.
The main philosophy of the Challenge is Learning by Doing. Instead of memorizing theory, you learn by building things yourself.
However, the optimal approach is different for everyone. Some people quickly skim the core concepts recommended by the Challenge and immediately start coding, learning by researching only when they get stuck. I also think that approach can be very effective.
But if you are someone like me who lacks basic knowledge and sometimes cannot even fully understand the problem at first, it may be better to focus on learning first and then review that learning through implementation.
In my case, the amount of CS knowledge I already knew was extremely limited. So although the ratio of learning and implementation changed every day, I tried to approach the missions roughly in the following way.
I quickly scan the keywords of the day and try to understand the general topic.
The goal is simply to think, “Ah, today we’re dealing with something like this.”
During the peak time (12:00–19:00), I spend a large portion of the time studying.
Depending on the mission, there were days when I mostly studied and implemented very little. I spent less time implementing than others, but I felt that strengthening my fundamentals was more important for me than quickly implementing something with AI assistance.
I try to define things such as data structures and module separation as clearly as possible.
In the Basic phase, I usually wrote the design while implementing the checklist items provided. However, the Challenge tasks were larger and there was not enough time to continuously rewrite the design while coding.
So I tried to decide as much as possible in advance about how each part would be implemented.
Even with that preparation, many revisions still happened.
While implementing, I refined the design and sometimes returned to learning again.
Especially in later weeks, insights gained from peer feedback sometimes led me to redesign parts of the system. I also used AI to review my code and summarize what I had learned.
The most important thing here was that I did not decide the “yak‑shaving level” alone.
For someone like me who did not even know how deeply a topic should be studied, the biggest question was always: “How far should I dig into this today?”
I adjusted this together with AI. When AI suggested a minimal learning outline, I adjusted the depth and order myself so that the learning could fit within the available time.
I believe the biggest insight the Challenge tries to give participants is learning how to find a learning strategy that fits yourself and applying it to your future growth.
The Challenge was honestly extremely difficult.
Some people described it as “solving in one day what would normally be a midterm or final project in a university class that lasts two or three weeks.” For me it felt even harder than that.
Students with a CS background at least had some basic framework to start from. I felt like I was starting from zero every single day.
Even those with CS backgrounds often said that the Challenge tasks required implementing things more deeply and at a lower level than typical university assignments. That alone shows how demanding the Challenge was.
Most days I spent the entire peak time (12:00–19:00) studying, and only started implementing later in the evening with the help of AI.
Sometimes it was 7pm, sometimes even the next morning before I finally thought, “Okay, now I should start implementing.”
The real challenge was deciding:
During the first week, I tried to survive by barely sleeping, thinking only “I just have to finish this somehow.”
But this led to problems. At one point I even missed the Friday reflection session because I was too exhausted.
After that I changed my strategy.
I still didn’t sleep much, but I tried to guarantee at least the minimum amount of sleep needed to give peer feedback with a clear mind. I realized that working while completely exhausted only made things less efficient.
During the Challenge there were three types of team activities.
Previously, when reading other people’s code, I tended to skim it quickly and move on.
But in this assignment we had to evaluate each other’s code across several criteria, such as readability, structure, and comments.
Because of this task I made a serious effort to read other people’s code carefully from beginning to end.
At first it was difficult to follow even a few lines, but gradually I started to understand the reasoning process behind someone else’s code.
I could notice things like:
Since other team members also had to read my code, I became more careful about variable names, folder structure, and writing helpful README documentation.
One teammate told me near the end of the program that “reading the README was fun because it clearly showed the thought process.”
That comment stayed with me for a long time.
Even in areas I had not implemented myself, I gained many insights.
I often realized things like:
I also encountered approaches to writing object‑oriented code that I had not been familiar with before.
Personally, I focused mainly on improving readability rather than efficiency, but seeing how other participants improved performance through algorithms and optimization taught me a lot.
In the relay project, I tried to actively guide the conversation, summarize previous discussions from the week before, and propose new ideas.
Many people said I didn’t seem like an introvert at all.
But in reality I am extremely introverted. During the Challenge I simply tried my best to create synergy in the team and encourage the sharing of ideas.
Before starting the Challenge, I was already using AI tools more frequently than many other participants. For example, I had built a small music recommendation bot that helped me discover songs that matched my taste, and I sometimes used AI as an English conversation partner for practice.
However, during the Challenge, both the range and depth of how I used AI changed significantly. I learned the strengths and weaknesses of different AI tools much more clearly and had the opportunity to experiment with a variety of new ones.
Tools such as NotebookLM, which answers questions only using the documents you provide and therefore reduces information contamination, and Lilly, which analyzes YouTube videos, were tools I tried for the first time and found extremely useful.
I also diversified the ways I interacted with AI. Through assignments that encouraged experimenting with different AI usage patterns, I began to think about more efficient ways to work with AI rather than simply asking it for answers.
Some methods that stayed with me were:
I had previously assumed that if I studied something once it would naturally stay in my memory. But revisiting my own code and asking AI to help me review my learning helped me reinforce those foundations much more effectively.
In an era where AI is everywhere, I don’t think becoming a developer who is "different from AI" means completely avoiding AI tools. Instead, it is more important to learn how to use AI intelligently and efficiently as a partner in growth.
The biggest difficulty I experienced was that my lack of fundamental CS knowledge sometimes made it difficult to fully follow discussions during peer feedback or Slack conversations.
Especially when topics related to performance optimization or algorithmic improvements appeared, I often found myself simply nodding along while thinking, “I should study that later.”
To participate in meaningful technical discussions with colleagues in the future, I realized that I still need to strengthen my CS fundamentals significantly.
To be honest, rather than "enjoying" the Challenge the way some people seemed to, I often felt like I was simply enduring it.
I spent four weeks sleeping only two to four hours per night, finishing assignments late at night and starting the next day again in the morning.
While the Challenge is designed to be intense, I also realized that long-term learning requires a better balance between physical health and study.
At the beginning of the program I worked very hard on writing detailed README files. However, as the weeks passed, I gradually focused more on implementation and simplified the documentation, leaving out parts of my reasoning process.
The kind of developer I want to become is someone who communicates clearly through readable code and well-structured documentation, making collaboration easier.
Technical skills are important, but the ability to share knowledge and collaborate effectively is equally important. I hope to return to that mindset again moving forward.
Even before the Challenge, I understood that design was important. But in practice I often jumped straight into implementation and only later modified the design repeatedly.
Experiencing the Challenge—which involved much larger and more complex tasks—made me realize again how critical design and breaking problems into smaller steps really are.
Instead of immediately starting to code, I tried to first clarify:
To better manage time, identify blockers, and maintain motivation, I tried to divide implementation tasks into very small steps.
In the Basic phase there had been checklists provided, so I did not pay much attention to this process. But during the Challenge I had to create those checklists myself, which made me realize how important they were.
Rather than using AI simply as a search engine, I used it to:
Of course, to become a developer who can think independently, I still need to focus on my own design decisions. But through this process I learned many new ways to work with AI.
On the day of the Challenge completion ceremony, we all listened to the song Butterfly together.
Recently I had also been listening to old anime songs like "Grip!" or "Our Dream". Looking back, I think I was drawn to those songs because they reminded me not to give up and to keep going until the end.
For four weeks, I stayed up late working on assignments, woke up the next morning to continue studying, and kept telling myself that I had to make it through another day.
There were moments when I wanted to quit. Sometimes I felt like everyone else was doing better than me, which made me question whether I truly had the talent for this field.
My computer even broke down in the middle of the program, causing me to miss a mission. At one point I lost code because I forgot to push changes while switching between my laptop and desktop.
Even so, although it wasn’t perfect, I did my best every single day without giving up. Because of that, I believe this will remain a very meaningful memory for me.
I want to carry the insights I gained during these four weeks into my lifelong learning journey.
From now on, I hope to continue growing as a developer at my own pace and in my own way—but consistently.
Thank you for reading.
And starting tomorrow, the Membership phase begins.
