Leaving the Company I Worked at for 2 Years

Today, August 16, 2019 was my last day at the company I’ve worked at for the past 2 years. I’m currently enjoying my final days at the office while writing this opening. So in this post I want to reflect on what I felt while working at this company over the past 2 years and how things have changed compared to when I first joined.

When I first joined this company, it was a new startup with about 13 employees that hadn’t received Series A investment yet, but now it’s become a company that received about 12 billion won in Series B investment with around 50 employees. This was my first time experiencing a company grow like this, so there were fun parts, but I also felt nostalgic for when the company was smaller watching the company culture and organizational atmosphere change as the organization grew.

Anyway, I’m quitting the company today for rest and recharge, so let me reflect from memories of when I joined to today, 2 years later.

The Legacy Code I Created

Before joining this company, I was an idle developer who spectacularly failed a startup with someone I knew and was playing around making various toy projects alone for about 2 months. One day, while coding alone at my regular cafe in Hongdae, some strange foreign guy sent me an interview offer message on LinkedIn.

After exchanging a few words, the service he was making seemed interesting, and the company’s atmosphere and vision seemed to match me well, so I interviewed the next week and got hired on the spot right after the interview ended. The only Q&A from that time I still remember is this one:

CTO: Can you do VueJS by any chance? We’re trying to make something like this… (showing components from another service)

Me: I’ve barely used Vue… but I think I can make it if I study personally while working.

Thinking back after the interview, I thought “what did these people even see in me to hire me…?” - but I could understand the current situation on my first day. First, I was this company’s first frontend developer. The CTO had been operating an existing Django-only project and felt the need for a frontend framework, tried introducing React once but failed, and as a fallback somehow got Vue barely working.

But since the CTO was a backend developer at the time, they wanted someone with frontend expertise to break through this situation, so I was chosen. So the first work I did after joining was using Gulp and Webpack to create the frontend build process and integrate the bundled files with Django.

But due to the business situation at the time, we couldn’t completely separate the frontend application from Django, so we had no choice but to apply a method where Django renders HTML once using its own template engine on the server, then Vue performs secondary rendering on the client.

And searching “Django Vue” on Google in 2019 now shows several posts explaining how to use Django templates and Vue simultaneously, but when I was doing this work in May 2017, not a single such reference existed, so I had to design everything myself and come up with ideas to integrate them.

I should have written a post about this work back then, but I’d just joined so I was too busy just understanding the entire codebase to think about posting.

Ultimately this application is now called legacy by the current frontend chapter and became an application that nobody including me wants to touch - but honestly it was the best choice at that time so I don’t regret that decision. However, it was my first experience having code I wrote get called legacy by other developers over time, which was kind of interesting.

This code had such a deformed structure difficult for typical frontend developers to understand that even while making it I thought “this will definitely be a problem later…?”

Listing all the problems is hard, but representative issues were: multiple Vue instances existing, parts requiring Django knowledge to modify, and impossible complete migration from bower to npm since the existing code used bower packages. Of course, these issues are ongoing.

These things pile up one by one to accumulate technical debt, so it had to be paid off someday. So I signed a 2-month freelance contract with my current company after resignation to migrate all frontend applications attached to this legacy application to a newly made frontend application project. (Like cleaning up my own mess)

From Tech Supremacist to Developer Who Sees Organizations

I mentioned this once in a post called What Is a Good Developer?, but when I first joined this company, my standard for a good developer was “a developer who develops requirements quickly and perfectly” and my development style was “makes things fast but has many small bugs.”

So I tried to defend against my unreliable code through unit tests or design patterns that can reduce mistakes to supplement this weakness.

But unlike my first job, here the CTO didn’t make all decisions - frontend developers made decisions about frontend applications. I had to do not just supplementing my weaknesses but also design and infrastructure that can flexibly respond to business, analyzing current application problems, and much more. Also, communicating outside the team was something I as a frontend developer had to do directly. (Especially communicated a lot with the marketing team about SEO, user behavior data collection, etc.)

Through this process, my conception of development expanded greatly - whereas before I mainly pondered “how can I develop better?”, after going through this process I pondered more “how can this application improve?” Going further, now I’m pondering not just applications but “how can this team work more efficiently?”

What Being the Same Team Means

Not long after I joined, the company received Series A investment, and the CEO’s promise then was “let’s go on a workshop abroad when we get investment!” So barely a month after joining I went on a workshop to Danang, Vietnam. (Jackpot)

It was about 3 nights 4 days I think, but the problem exploded the night before returning to Korea. A feature I’d developed before coming on the workshop wasn’t working at all in Internet Explorer. That feature had been deployed for about 3 weeks, and as users couldn’t use that feature in IE, the data flow chart started drawing strangely.

Since not a single person in the company used IE at the time, we didn’t discover this problem early. But the biggest responsibility lay with me who developed that feature and didn’t properly test cross-browsing. So I immediately opened my MacBook and started hotfixing when I heard about it, but the time was already past midnight.

The emotions I felt then were, um, self-blame for not testing properly and guilt for causing damage to the company through my carelessness. Anyway, I had to fix this quickly so I frantically analyzed and found the cause - the biggest problem was Array.prototype.findIndex method wasn’t properly transpiled by babel, plus several other minor issues. (I haven’t trusted babel since)

Fortunately I quickly found the bug cause, but the real problem was Vietnam’s internet was too slow, so building source and checking that feature’s operation took long, and since the problem area was a module handling API communication with the server, I had to test all core features using that module. Plus, the build process suddenly went haywire while fixing it and other problems cascaded, so fix time kept increasing.

Nostalgic commits from that day

Ultimately various issues overlapped and the final release could only happen past 5am. The important point here is that all team members stayed up all night with me until then. Actually this was 100% a frontend issue. I was the only frontend developer at the time and the rest were all mobile app developers and backend developers, so other developers couldn’t help with the fix. Plus, among those who stayed up all night with me was a UI/UX designer.

Team members who kept watch beside me even at 1am

I felt both sorry and extremely grateful to team members then. While I was panicking and fixing bugs, team members encouraged me saying it’s okay so fix it slowly and carefully, brought me food, and asked if there was anything they could help with.

They were such grateful people that I wondered whether I’d meet a team like this again at other companies, and even now after everyone has gone their separate ways, we still keep in touch regularly. (I even received a farewell gift yesterday.)

I actually had strong individualistic tendencies, but experiences like these became precious experiences that made me steadily ponder the team’s development.

Becoming Someone Who Helps Others

Around last summer, someone who’d worked in the CX team since I joined came to be a PO (Product Owner) through a position change. Of course, since this person’s major wasn’t this field and they had almost no experience doing product-related work, they were no different from a newcomer.

Then as teams were divided into squad formations, this person and I came to work together in the same squad - when first working together I honestly didn’t pay much attention to them. Like they’ll do well on their own… or even if they don’t, I or someone can cover? That level.

But working together I saw many new aspects of this person I didn’t know before. Though they had less experience than others, they were extremely passionate about making products, and also asked many questions - the quality of questions was quite good. Maybe that’s why, every time this person asked me development questions, I gradually taught with more enthusiasm, and this person always thanked me a lot for that.

I also felt really good seeing that person grow quickly as I taught them knowledge I knew. I think I first thought then that knowledge I already knew and thought was nothing much could be tremendous help to others.

And that person’s squad operation style was participatory where developers and designers all freely suggest ideas and they aggregate and organize them while proceeding - as that person’s experience and skills accumulated, synergy effects occurred so the team’s productivity increased and I remember the team’s morale and atmosphere being very good. Ultimately, my action of teaching that person development knowledge affected not just me and that person but the entire team.

Going through such processes, I no longer agreed with thoughts like “if individuals each do well, the team runs well on its own.”

From Loner to Somewhat Social

I originally didn’t like meeting people much. But going through many things at this job, my personality kind of changed…? I suddenly started acting social.

When I first joined, there was a backend developer who joined within a few days of me - for about a month after joining we barely talked besides work because I had no interest in people. (This person was also shy so neither of us talked much)

But now when someone new joins I talk to them first and drink or play games with other teams, acting social - thinking about it now, last year’s burnout was probably the catalyst.

I experienced severe burnout around summer 2018 - until then I was someone who coded every single day of the year, 365 days. On weekdays I worked overtime until 11pm, came home and did toy projects until 2-3am, on weekends I did other toy projects with friends - that kind of period. I probably coded at least 7 hours every day all week like that.

I’d lived this way continuously since 2014 when I returned to university after military discharge, so by 2018 when burnout came I’d lived like that for about 5 years. Then burnout suddenly hit - I just lost interest in coding itself and didn’t want to do anything.

My sparse 2018 GitHub contributions

Even thinking about it now, it was an extremely bewildering emotion. Someone who coded 7-8 hours every day for 5 years because coding was so fun and enjoyable suddenly hating coding overnight is quite a strange feeling. I felt skepticism like “why do I need to struggle this hard?” and simultaneously felt anxiety like “am I falling behind?” I think I also thought “maybe development doesn’t suit me?”

What I did wrong at this time was showing too obviously that I didn’t want to work. My inner thoughts then were “ah, it’s so boring and hard. Should I quit the company…?” so I distanced myself from team members and my work attitude was poor. During the day I worked half-heartedly and finished work by working overtime alone, so work didn’t pile up, but I couldn’t communicate much with team members.

Hearing about it later, team members who’d worked with me long thought “this guy suddenly went weird…?” and approached me first, but other team members who didn’t know me well apparently thought I wasn’t working properly. So the team leader asked for tea time and we talked briefly - what that person said then still remains in my memory.

Evan’s hardship isn’t Evan’s personal problem but the team’s problem. The team will help as much as possible.

But you need to tell us what’s making it hard.

Hearing this, I wasn’t exactly moved but freshly thought again “right. We’re a team.” So from then I explained my current situation to people around me and could hear much advice - everyone around me said exactly the same thing: “rest a bit.”

The life of working overtime daily, coding on weekends, having no hobbies and not dating made me exhausted. This fatigue tends to build up sneakily then explode bang! when passing some threshold, and now was exactly that timing. So everyone advised me to rest while doing other things besides coding.

People around me told me things like this regularly

So I lived a debauched life by my standards to relieve stress - drinking, playing pool, going to karaoke almost daily - and I could become close with people from teams besides the development team. When playing with the development team, we mostly talked about programming or organizational culture, somewhat work-related topics, but drinking with other teams I could hear new stories which was good.

The experiences of hearing other teams’ stories became a foundation for me to understand and be more considerate of other teams’ situations when working at the company.

Stimulation from Capable Team Members

This is also subjective evaluation, but I think most teammates I worked with at this job over the past 2 years were self-directed in their work, made proactive decisions, and had good skills in their specialized fields. Of course, I’m not just talking about developers but including people from other teams.

Of course, I received the most stimulation from developers working on the same team, and the teammate who stimulated me most was probably the same frontend developer. This person worked with me until yesterday - a senior frontend developer. This person isn’t the style who has tremendous passion for development and studies at home and such. But the ideas they casually toss out are so novel they can solve problems immediately.

Of course, these ideas couldn’t come without deep understanding of JavaScript, and seeing this person solve in one shot a problem I’d pondered for a week just two days after joining made me think again “there really are many experts in the world.”

It was a kind of timing issue where I couldn’t know when external SDK script loading finished, so the global variable holding that SDK was null during application initialization - I’d barely gotten it working with setTimeout and had no more ideas so left it alone. But this person saw this problem and immediately solved it by declaring an isLoaded variable as a Promise and resolving that promise when external SDK loading finished. (Even now thinking about it, it’s a perverted but novel method.)

And this person also solved the memory leak in the frontend render server I wrote with Express - I’d improved this problem several times so it was fine for now, but leaks themselves still occurred bit by bit. Meanwhile, when this senior updated external packages used in frontend, the memory leak suddenly accelerated. But I couldn’t identify this problem’s fundamental cause. So this person took this issue and decided to fix it, and I remember being quite surprised they solved the problem faster than expected.

Dramatic change in transaction time

It was a leak occurring when some external packages designed to only be usable on the client were used during server-side rendering timing - I hadn’t even thought of this case as a possibility.

Besides that, I was also positively influenced a lot by a backend developer I worked with long regarding design and perspectives on business, and learned passion for products from a mobile developer who likes working overtime. Honestly I learned too much from team members to list everything one by one, so I’ll stop here. (They’ll probably all know who they are just from reading this)

Wrapping Up

I want to express gratitude to team members who experienced so many things together in this team over the past 2 years.

The 2 years working with you all were opportunities to learn tremendously many things as a developer and as a human being regardless of career or position. From non-developers I could also learn knowledge from other fields beyond development. To me, you all were sometimes professional teammates and sometimes felt like friends working together. Though I’m leaving the company and can’t work together anymore, I hope we can meet again somewhere else.

I end this post expressing thanks to everyone who made good memories over 2 years.