2020, How Did I Grow? A Mid-Level Developer's Retrospective

2020 was an eventful year both personally and globally. Especially COVID-19 that swept the world changed so many things. Personally, not being able to meet people was a bit hard. (First time in my life I haven’t gone to karaoke this much…)

Despite all that, I took on various challenges. Some succeeded, but of course some failed. Even failed attempts taught me lessons, becoming good development opportunities.

In this post, I’ll look back on the major events I experienced this year and reflect on the lessons learned.

A Year at Toss

I joined Viva Republica, which makes the financial platform service Toss, on December 9, 2019. Right after joining, I was placed in the Insurtech silo handling the insurance domain, staying involved in this silo’s goals for a year without changing teams.

Steel plate received when we achieved BEP

Thinking back to my first day, I remember the existing Insurtech silo team members welcoming me warmly. At the time, the frontend position in the Insurtech silo was vacant, so when work requiring frontend came up, either the product designer did markup directly or we got support from frontend developers in other silos.

Those expectations felt a bit burdensome, but everyone helped me adapt well and made me comfortable, so I could quickly follow up on past history and get involved in the Insurtech silo’s goals.

Also, the Toss team is quite lenient about failure compared to other organizations, and the speed of learning from these failures and applying them to the next challenge is very fast. For this reason, working here means the ideation, decision-making, development, deployment, and result analysis iterations repeat endlessly, making it fun but quite hectic.

That might be why this year flew by faster than usual.

Cleaning Up Legacy Code

My first product when I joined was an insurance-related internal product. At the time, this product didn’t even have TDS (Toss Design System) attached, was developed so urgently that the internal design wasn’t solid, and had development environment differences from other Toss products — there was a lot to improve.

When I first take on a product, I look through its commit history. Looking at commit history tells you how the product was developed following business context, and roughly what design direction the developer before me was trying to take.

After looking at this product’s commit history, my first thought was “the schedule was f***ing tight…” Usually with commits you can group them by feature — commits for feature A, commits for feature B — but this product had very short gaps between developing one feature and the next, and sometimes multiple features were developed in a single day.

But as always, you can’t carve out time for refactoring when you’re busy developing features to keep up with rapidly changing business context, so I had no choice but to refactor bit by bit following the Boy Scout Rule.

My refactoring goal at the time was simple:

Make it so any frontend developer at Toss could take over this product without feeling out of place!

I handled this product from December last year to August this year — roughly 9 months. The seemingly endless refactoring showed some results just by doing it steadily.

When I first arrived, deployment was done by manually running scripts, but now the process of developing features, raising PRs, and running CI/CD matches other Toss products, so other frontend developers can develop features and deploy in the same development environment.

Also, this product’s domain characteristic was complex models, naturally making client state very complex too. At the time, all this complex state was managed with context, so context was a messy mix of state-holding objects, dispatch functions for state changes, functions for async processing, reducers, etc.

So I introduced Redux, which Toss uses a lot, separated async processing functions into middleware, and split stores by data domain to make them somewhat easier to understand. The Redux introduction itself wasn’t high difficulty, and even with Redux the state complexity is still high, but I think matching the development environment with other Toss products has more significance.

There was also a problem synchronizing server state and client state. When initially developing this product, there wasn’t much time, so it was developed using a Poll method that called the API once per second. So state changes happened once per second, and worse, many components shared this state through Prop drilling based on Context, causing unnecessary rendering once per second too.

So I tried to improve rendering performance using Redux and react-redux hooks and change the API Poll to a Push method. But ultimately I only finished the Redux introduction and rendering optimization before this product left my hands.

Fortunately, when I mentioned this to the FE developer who took over this product, they empathized with the direction I was trying to take, and recently finished the refactoring by removing the Poll method and changing to Push. (Thanks to them, I took one burden off my mind)

Of course there are still many disappointing parts, but it feels good that it improved a lot compared to the beginning. I left at dawn several times because of this product and struggled whenever developing features, but I worked on it with affection for 9 months, so it became… a kind of love-hate relationship.

#sig-weekend-work Channel

Besides work, I also do toy projects and write blog posts, so on weekends I often gather with friends at nice cafes to eat delicious food and work together. Someone who heard about this suggested “Why not just create a weekend work channel on Toss Slack?”, so I created the #sig-weekend-work channel on Toss team Slack.

And so a channel that should never have opened was opened...

Honestly when creating the channel, I thought “How many people will even join?” But somehow these people sniffed it out from everywhere and just flooded into the channel.

I’d made similar proposals at my previous workplace saying “Who wants to work together on weekends?” but this was the first organization to show such an active response. That’s when I thought “These people… really love work…”

In April, when we went all the way to "River" cafe in Yangpyeong for weekend work

Honestly, when we go to nice cafes in the Seoul suburbs, we don’t just keep working. We look at scenery, eat delicious food, just play while also working. So I have fun memories of going to Seongsu, Yangpyeong, Yeongjongdo with weekend work members.

Changing Poll to Push mentioned above was also progressing like a side project, so I met with the backend developer from the same silo in Hongdae on a weekend. After about an hour of heated discussion, we aligned our directions and defined the channel interface — quite a fun memory.

Also, going to a Turkish restaurant in Songdo with weekend work members where we were the only Koreans felt like we were abroad, and playing billiards betting at the billiards hall behind the office after work was fun too.

Recently as COVID got serious, we stopped meeting on weekends like before, but when COVID recedes, I think this channel will reactivate.

One Direction, Various Methods

Working at any company, you face moments requiring decisions. In organizations I’ve experienced, someone with more say usually led decision-making, but the Toss team doesn’t have anyone with particularly strong say, so the decision-making process always involved fierce discussion and persuasion.

I had many such discussions over the past year, and I definitely feel I gained broader perspective to consider more diverse aspects compared to when I first joined Toss.

Personally, I think the topic where opinions split most in these discussions is the value called Customer Centric. Since customer-centricity is an abstract value, different people have different standards for “this is customer-centric.”

The phrase heard most often in meetings

Some people say showing customers as much information as possible so they can find what fits them is customer-centric. Others say showing customers only the most necessary information and preventing pointless worrying is customer-centric.

Especially since Customer Centric is a core value most people at Toss consider important, everyone finds it hard to compromise their own customer-centric values. Working here, you hear the question “Is this really Customer Centric?” quite often.

Working in an organization where people speak their minds freely for a year, I could better feel that even pursuing the same value, methods to achieve that value can differ greatly per person — not just for Customer Centric. And naturally this realization led to viewing problem-solving methods from various angles.

Lubycon, Rolling Together for 6 Years

Since university, I’ve been active in a team called Lubycon. It’s nothing grand — initially just friends gathering to make things they wanted and study together.

Lubycon comrades in a meeting

I created this team around 2015 when I returned to university, so I’ve been rolling with these people for 6 years now. Actually in 2019 we barely did anything besides hanging out because everyone was busy with work, but in 2020 the team atmosphere got busy again as we started a mentoring project together.

Mentoring Someone

Starting March 2020, the Lubycon team started a project mentoring methods for smooth collaboration, and through this process I gained many failures and learnings both personally and team-wise.

I’m not generous in self-evaluation. So I live whipping myself daily saying “still not enough.” This is less about my passion being great and more about fearing that the moment I think “I did well enough,” I’ll stop making efforts to grow. (Eventually this led to burnout, but habits don’t change easily…)

One thing I felt during this mentoring: I apply this standard not just to myself but to others too.

Regardless of skill level, I think we must constantly strive for growth. And to make such consistent effort, goal-setting and motivation must be clear.

So before becoming a developer, I tried experiencing various things — b-boying, composing, sound engineering, programming — to find “something I can do reasonably well while enjoying.”

This was how I grew, so naturally I thought this was the right method. Rather than just thinking with your head, move your body to try as many challenges as possible, see results, judge, then continue the next challenge. So when mentoring, I often told mentees these things.

When mentees said they struggled with the project because of work, or felt frustrated that skills weren’t improving, I didn’t really understand. Honestly, I thought it was just lack of passion and motivation. So I always told mentees things like:

• Hey, I did it, so there’s absolutely no reason you can’t. Try challenging it, and if it really doesn’t work, let’s talk again then!

• Of course you lack time for toy projects while working. You need to create time yourself, even by reducing sleep.

• Skills absolutely can’t improve quickly in the short term, so don’t be anxious. Just keep at it consistently and you’ll grow at some point. So you should cultivate the habit of coding even a little each day. Endure even if it’s hard.

This wasn't mentoring, it was professional whipping

I don’t think what I said then was wrong. You can’t reduce work hours just because you lack physical time to invest in personal growth due to work, so reducing sleep is a reasonable method. And the easiest way to improve skills is consistently training even a little daily, overcoming the feeling of difficulty and reluctance.

After 3 months of mentoring, we had a final retrospective, and the frontend developer from the team I mentored said:

I reduced sleep to do the toy project as you suggested, but lack of sleep kept making me lose focus and my physical condition worsened 😢

I didn’t show it, but hearing this felt like getting hit in the head with a hammer. That’s when I thought “Ah, I just had better stamina than them to handle that crazy schedule.”

Learning methods that work efficiently differ per person, but I just pushed what I’d done for the past 6 years thinking it was right. Of course, growth methods similar to mine work well for some people, but at least those I mentored weren’t people for whom this method worked well.

Ultimately, what I missed as a mentor was empathy and difference. When mentees said they were struggling, I didn’t empathize with the problem and try to solve it together. I just dismissed those as whining or amateurism, emphasizing only properly finishing the project even if pushing themselves to the extreme. (And I felt like an old fogy realizing this, so I was depressed for a while)

If you repeatedly don’t work because it’s hard, teammates’ trust will gradually disappear. This team has only one frontend, backend, and designer each, so if even one person doesn’t work, the project drops. Have responsibility. Give trust to colleagues. Along with these words.

These words are hard to call wrong, but a mentor who only pushes this way isn’t a good mentor — just a scolding teacher. A mentor should be able to maintain mentees’ morale and motivation to some degree, but I focused too much on launching the project itself.

So until last month I kept pondering answers to this problem. At the company I also received feedback to “become someone who thinks about not just individual growth but team growth,” making me want to find answers even more.

But I still don’t really know. Just empathizing unconditionally won’t help mentees grow, and just whipping doesn’t help either.

Ultimately you need to understand what growth methods work for the person, give appropriate motivation and advice, and bring out their potential. But analyzing people, not computers, is still too difficult for me.

Everyone’s Rolled A Lot…

I’d done retrospectives on things the Lubycon team did before, but never really thought about retrospecting the team itself. Recently as things to do together with these friends increased, some new thoughts started emerging.

While running the mentoring project mentioned earlier, I properly took on work with friends for the first time in a while. Working with friends like this, the feeling I recently felt was “Everyone’s really rolled a lot…” (Belatedly realizing this)

Now most have 5-6 years of experience as working professionals, but thinking back to university days, this team was just a total rookie gathering. More like a friend group than a toy project team. We didn’t know how to collaborate properly and fought all the time.

Of course, during semester or vacation we gathered daily in Dongguk University Panya Hall basement to ideate, develop, and design together, but back then it was more fun just hanging out with them than developing. Going to PC rooms to crush some games, drinking, billiards, karaoke, sometimes cursing each other out.

Then this year suddenly the team got busy with lots of work and collaboration increased dramatically. Watching everyone smoothly solve problems popping up everywhere felt a bit strange. In my memory, Lubycon was a team that did lots of fumbling and spent all day googling because we didn’t know methods, but at some point working in this team started feeling similar to working at the office with such smooth progress.

Recently there was a major accident where the DB table containing mentoring project applicant data got deleted while deploying a serverless framework application, but later we found out the friend in the DevOps role had been continuously backing up, so it passed without incident. When friction arose from project direction or Lubycon team agenda — macroscopic values — not syncing, I remember we also coordinated opinions well and solved it.

Let's make backups a lifestyle... that terrifying day's memory

Though each walked slightly different paths, rolling in the field for 6 years makes now being more grown than university days natural. But lately I keep thinking of memories fumbling back in university. Recently eating omakase in Gangnam with 2 Lubycon friends, remembering eating Hansot lunch boxes and jajangmyeon together when young felt strange.

Going forward, I hope we can do various activities matching Lubycon team’s slogan Growth and Share, sharing what we have with others. (Let’s build team name value, guys)

Blog Retrospective

I’ve been steadily writing my blog since June last year, and while I looked at data fragmentarily until now, I never looked at overall data from start to today. So this time I’ll share some blog content.

Actually I connected Google Analytics and Amplitude event tracking solutions to my blog and observed people’s behavior. (Saying it this way makes it sound like civilian surveillance)

Since this blog isn’t a commercial service, just my hobby space, I don’t need to deep dive into data analysis. So I just use it to learn what readers are interested in and what information they gain.

Blog Visitors and Bounce Rate

I started blogging seriously in June 2019, so let’s look at blog visit data from January 2019 to December 30, 2020 when I’m writing this post.

In May 2019 before I started blog activities seriously, monthly visitors were about 60, but in June 2019 when I started, it increased to about 4,000.

Rather than writing particularly good posts, I posted 9 posts just in June 2019, so inflow probably increased this dramatically. And currently in December 2020, monthly visitors are about 20,000, total pageviews about 470,000.

What’s unique in this data: the bounce rate is only 64.94%. Usually services focused on information delivery like blogs have high bounce rates when users get the information they want. So this bounce rate is pretty good for a blog.

But it’s still a bit disappointing to just give up on bounce rate, because of this data:

This chart shows the rate users read another post after reading one blog post in the last 30 days. The leftmost chart is users who saw 1 post, and the right charts show users who saw 2, 3, 4, 5 posts.

Just looking at the chart, you can see user numbers sharply drop going from the leftmost to second chart, meaning many users bounce after seeing just one post.

Up to here is natural given blog service characteristics with high bounce rates as mentioned, but what’s interesting is the percentage passing through those funnels keeps rising.

post1	post2	post3	post4	post5
100%	16.9%	37%	51%	62.3%

post1 is people who saw one post, set as 100%. post{n} columns show percentages of people from the previous funnel.

So post2 means only 16.9% who read the first post read a second post. Similarly post3 means 37% of those who read the second post read a third.

But looking closely, numbers rise after reading the second post. So the more posts you read, the higher the probability of getting interested in my blog and reading more posts.

So seeing this data, I tried improving bounce rate by adding related posts, grouping by tags, etc. — but to conclude, all failed. I should analyze this more and run tests when I have time.

Visitor Segments

My blog has lots of technical content, so my blog’s user segment is limited to people doing technology-related work in IT. (Sometimes marketers come in through GTM posts)

Everyone seems to rest on Saturday, but why do they come in on Sunday...?

This chart means darker shading indicates larger values. My blog visitors mainly access between 8 AM and 12 PM on weekdays, probably from googling problems while working and discovering my blog.

Looking closely, from Friday 7 PM to Sunday 11 PM — basically the weekend — even dark shaded parts don’t differ much from light parts. The color looks like that just because values exceed 1500, but actually values stay between 1400-1600 during those hours.

Looking at this, I can hypothesize users visit my blog not for killing time but for practical work help.

Other user segment factors include age and gender, which you can probably guess:

Though the development field’s gender ratio improved compared to before, it’s still male-dominated. My blog visitors are also 77.7% male and 22.3% female, showing much higher male ratio, with main age group being 25-34.

So the main persona of users primarily using my blog would be male developers in late 20s or early 30s. Of course, since I won’t market or run events targeting this user segment — just run a blog writing technical information — this analysis doesn’t mean much.

Search Inflow Keywords

Like most blogs, mine also lives on organic traffic flowing in from search engines like Google. Looking at Google Analytics channel inflow data, organic traffic occupies over 50%.

Top organic inflow is 50.6%, 2nd SNS channel inflow is 21.7%.

In this situation, I naturally get interested in what search terms bring people to my blog. This data can be seen in more detail in Search Console than Google Analytics.

Search result impressions and clicks trend upward, but CTR doesn't grow well

My blog appeared about 1,800,000 times in search results from January last year until now, clicked about 125,000 times. Average CTR so far is about 7%.

Looking at the chart’s rightmost part, you can see metrics dropping. This year-end metric decline trend appeared the same last year.

Last year seeing this I thought it dropped because of many year-end appointments, but seeing it the same this year when COVID prevents making appointments, it seems people don’t work much at year-end regardless of appointments.

Recently Google launched Search Console Insights that organizes and shows these data as summaries. Looking here definitely shows at a glance what search terms brought people to my blog in the last month, what sites backlinked my blog.

Undisputed 1st place: CORS...

As this data shows, 4 of the top 5 search keywords flowing to my blog are CORS policy violation-related keywords.

Actually the post Why Does CORS Make Our Lives So Hard? written in May this year has had consistent traffic inflow from then until now, showing many people struggle solving CORS policy violations.

The backpropagation keyword in the middle leads to the [Deep Learning Series] Understanding Backpropagation post written in 2018. Probably manually solving the backpropagation algorithm step by step and porting to code helped people entering machine learning.

Besides these, posts on topics directly related to programming like HTTP3, TCP, Git, math mainly rank high, while posts on non-CS developers or business philosophy relatively lag behind.

Let’s Prepare an Inflearn Course!

In last year’s retrospective End of My 20s, Looking Back at 2019, I said I wanted to try presentations or lectures in 2020, and finally started preparing a course recently.

Someone around me says the developer’s 3 great lies are toy projects, changing jobs, and YouTube/Inflearn. I also kept lying throughout 2020, starting this challenge only as 2020 was ending.

Going to challenge making lies reality

I finished writing the course curriculum last week and am now writing scripts, but this is a different feeling from writing blogs or books, causing various difficulties. Since it’s a script, writing in spoken rather than written style reads better later, but I keep habitually writing in written style, making it too stiff when reading. (Doing a one-man lecture show while writing seems to help a bit…?)

Of course, I have a long way to finish the script, but even if it takes time, I’m aiming to write steadily daily, so I’ll finish eventually. Honestly, once I write about half, no matter how hard it gets, I’ll have to finish because of sunk cost.

Sending Off 2020

Looking back at 2020, there weren’t many dramatic challenges. If I had to pick one, maybe the mentoring project…?

In June we held a mentoring demo day at Cow & Dog in Seongsu

Actually just mentoring alone was so physically and mentally draining that I couldn’t muster courage for anything else. Since this was my first time mentoring, I didn’t know giving someone attention and leading them required so many resources.

Until now I was a developer who only took care of my own growth. I thought each person’s growth, whether soft skills or hard skills, was something each person had to manage. Then individual growth would lead to team growth. If a teammate didn’t grow as much as others, of course you should help your best, but if they still can’t keep up even with help, ultimately cutting them off was right.

But during this mentoring, doubts started sprouting that this thinking might be wrong. Just vaguely helping isn’t the answer. Depending on who leads and mentors how, this person’s potential could burst out or die right there.

As I gradually build my career, I could become someone’s mentor, someone’s role model, or a leader of some team. I think it’s time for deep contemplation on whether I can properly perform that role when the situation comes.

I can’t be a developer who only looks after my own growth forever. Now I need to look after not just myself but organizational growth too.

So recently I’ve been talking with fellow developers about topics like “What is a senior developer?”, got recommended and am reading the book Growing Together, but haven’t found answers on what methods are right yet.

In 2020 I end this retrospective with questions I couldn’t answer. But for my 2021 retrospective next year, I’ll set a goal to find answers to these questions and concerns and write them in the retrospective.