Retrospective on Lubycon & Clelab

---

Why Did I Join Clelab (Lubycon)?

To explain this, I think I need to briefly share why I became a developer in the first place!

I became a developer simply because I enjoyed building things. After becoming one, I felt great satisfaction whenever the services I built turned out to be helpful to users, and I lived my life as a developer thinking of myself as a creative!

But I wasn't finding much fun in my personal side projects, and I could feel myself starting to drift into a slump.

Looking back, maybe it was because I wasn't pouring my heart into projects at work, or maybe the domain just wasn't one I cared about, so I enjoyed it less.

Right around that time, a chance to join Clelab came along. Clelab is a team with the mission of gathering great articles scattered across Google and packaging them into a single course for developers. I strongly wanted to help tackle that mission with them, and it sounded genuinely fun, so I decided to join :D

Clelab Is a Side Project — How Do We Manage the Schedule?

Clelab operates based on the Agile methodology,

and we break issues down into one-week sprints, running a retrospective at the end of each week.

You might wonder, "It's just a side project — can it really be managed well?"

But over more than 20 sprints, everyone has been running beautifully toward our goals!

How Does Clelab Set and Act on Priorities?

Clelab uses Amplitude and GA to collect data, and based on that data we decide which features to improve or add, and then we execute.

Looking Back on My Time With Clelab and Lubycon

There are two main things I realized while working on Clelab.

1. What kind of developer do I want to become?
2. Where am I currently lacking as a frontend developer?

What Kind of Developer Do I Want to Become?

Through my time at Lubycon and Clelab, I had been questioning what kind of developer I wanted to be and what values I wanted to center my work around.

Through these activities, I realized that I feel enormous satisfaction when the services (products) I build turn out to be helpful to the users who use them, and I sensed that this realization would have a big impact on my future career.

Where Am I Currently Lacking as a Frontend Developer?

• As a frontend developer, I don't put enough thought into building flexible components.
• I wasn't thinking of code review as a space for mutual communication.

1. As a frontend developer, I don't put enough thought into writing flexible code.

   While working on Clelab and Lubycon, I've witnessed countless code reviews firsthand and received reviews on code I wrote myself.

As the code review scenes above show, Lubycon has a very active code review culture. Members ask about the author's reasoning or suggest better directions so that the product as a whole can improve!

Hearing the feedback above, I had one of those "oh no" moments and was a little disappointed in myself.

If I had looked at the code a bit more carefully — if I had thought about it more thoroughly — I surely could have caught it.

Thankfully it was pointed out in review and turned into a common component, but what if it hadn't been?

The next time a similar UI came up, I would have scrambled to build it from scratch and patch the existing logic all over again.

In other words, we prevented something that would have easily doubled the effort down the road.

Going through that code review made me realize I need to build the habit of seriously considering — while I'm working — whether a UI or function can be used as a reusable module.

I Wasn't Thinking of Code Review as a Space for Mutual Communication

Lubycon has chapters for each discipline. I belong to the frontend chapter,

and the frontend chapter builds and maintains a utility library of tools that frontend developers need in their day-to-day work.

Maybe because I felt like my skills weren't up to par? I hadn't been leaving any real opinions or questions on code reviews other developers opened — I was just lurking.

In truth, Lubycon treats the Merge Request space where code reviews happen as a "space for communication" — a place to view code from different angles and exchange opinions about it.

Up until now, I had been treating code review less as a "space for communication" and more as a space where my code gets evaluated, which is probably why I was acting more defensively.

Wrapping Up

I've written this retrospective on what I've felt throughout my time with Lubycon and Clelab.

I think it has been a wonderful opportunity to grow, and I plan to work on shoring up the weaknesses I identified.

If you're a junior developer who wants to grow and wants the experience of building and shipping a real service, I'd encourage you to give it a try.

That's the end of my retrospective. Thank you for reading 🙌