RIDI (Jun 2016 ~ Mar 2018)

Junior versus experienced hire

The second company changed me a lot. I got a MacBook. Until then I had developed on Windows and never used one. I had to learn macOS first. Everything else was new too. My first job had used SVN; here I learned Git. The languages were unfamiliar PHP and JavaScript. PHP was completely new—I spent about a week on syntax, the Laravel framework, and Doctrine ORM. We tracked work in Asana and I used Slack for the first time.

The bigger shift was being an experienced hire rather than a new grad. The gap between junior and experienced hire is real. As a junior I could say when I did not know and lean on everyone without shame. As someone with a résumé, admitting ignorance got harder. At that level you are expected to produce answers anyway.

I was picking up the new language and stack and mostly touching back-office code. About a month in, my manager asked for a chat. The company was planning a new service and spinning up a team; he wanted me on it. I said yes without hesitating. I figured I would learn more greenfield than by nibbling at an existing system, and we could pick our own stack as a team. I moved to the Ridistory development team.

Building a new service

The team was just two people. We were hiring but still at the résumé stage, so the squad was whoever had transferred from other teams. Requirements were not fully fixed, but we needed to move fast to claim the market. Team formation was around August; we had to ship Android and iOS apps by year-end. We guessed at the product spec and started from the backend. With only two of us, there was no fine slicing of roles—we each did as much as we could.

We spent about a week choosing backend language and framework among Python + Django, Ruby on Rails, and Java + Spring Boot. I set Rails aside—not only hiring, but the ecosystem felt less alive than the others. Personally I leaned Java + Spring: I wanted production Spring experience and assumed hiring would be easier. We chose Python + Django. All three were new to us, but Python + Django looked like the gentlest ramp, and Django shipped an admin UI—important when time and headcount were tight. Building a separate back office was less attractive than leaning on Django admin. I still think that call was right.

We leaned on AWS: EC2, RDS, ElastiCache, CloudFront, S3, CloudWatch, and so on. I was weak on typical web infra, so my manager made most decisions while I helped stand up services. Ansible was handy for deploy and provisioning. We used self-hosted GitLab and later touched GitLab CI lightly for CI.

We posted openings and interviewed many times. Without that crunch, a short résumé like mine would rarely have sat on the interviewer side. Every loop needed a panel, so I kept going. Strong candidates applied; we tried to favor people who already knew our stack because the schedule was brutal.

Sitting on the other side of the table showed me things I had missed as a candidate. I realized candidates would remember RIDI partly through my questions and tone—that was the company’s face to them. The seat felt heavier. I also learned that reading résumés carefully and preparing questions pays off when deciding yes or no. After several rounds we hired two more developers.

Front-end work

Ridistory was a web app at the time. The front end used Jinja2 templates—the classic server-rendered style. Without an SPA, every navigation flashed white and hurt UX. That nagged at us while we built; eventually we decided to redo the front end. Going fully native was impossible, so we aligned on an SPA and React.

I had taught myself React, but I was not a front-end specialist and had never used it professionally—my depth was shallow. Still, I was the only person on the team with any React exposure, so I led the charge. I ported template pages to React, wrote down what we considered best practice, and spread it to the team. Fortunately everyone was strong in JavaScript, so the port moved faster than expected.

Launch

We launched early the following year, a bit behind the original date. Ridibooks had a large user base, so traffic showed up from day one. The night before, I stayed up finishing prep; at 9 a.m. we opened the gates and people poured in. I had not slept but could not look away from dashboards and the database for fear of a surprise outage. The first day passed without a major incident.

Running a service, you cannot dodge incidents forever. Early on they happened often. We did not have enough people for a dedicated on-call rotation, so I carried my MacBook on evening walks with my wife and watched Slack like a hawk.

Then Lunar New Year approached. Covering the whole long break would burn everyone out, so we split it: my manager took the first half, I took the second. We prepared as well as we could, but worry became reality. My manager once had to open his laptop in a corner during a family holiday rite when Slack blew up.

As usage grew, product wanted to mine the data we were storing. Everyone could SQL, so we did not need query tutorials—but sometimes people were too good and submitted heavy queries against production. Monitoring showed resource spikes whenever analytics queries ran. We concluded we needed a separate database for analysis. The wrinkle was that data already lived in separate databases ahead of possible sharding, and product wanted JOINs across them. We first tried the Federated engine to present one logical DB, but load still hit the primaries, so it did not solve the ops problem. We pivoted to dedicated analytics replicas fed by replication from each shard. MySQL replication is usually one master to many slaves; fortunately multi-source replication landed in 5.7. RDS did not expose it—no console support and no superuser for replication setup—so we installed MySQL on EC2 and wired multi-source by hand. For a non-critical analytics box, that was cheaper than RDS anyway.

Study culture

On Ridistory we studied constantly. The team loved learning new tech and applying it. That culture ran through RIDI as a whole. Every hire, junior or senior, had to complete a Clean Code study; spinning up voluntary study groups was normal. We ran sessions on TDD, DDD, Spring + Kotlin, and more. DDD was so dense we did a second pass with another book.

Spring + Kotlin was less idle curiosity and more “what replaces Python + Django?” Django had launched us fast, but as the service grew we hit limits. Django did not play nicely with DDD, and we sometimes had to hack deep inside the framework—version upgrades became painful.

After the Spring + Kotlin study we prototyped for about a week (I think a video shop) to decide on adoption. I do not remember every detail of the retrospective, but we did not switch. Kotlin on the backend was still early, references were thin, and the payoff did not justify the porting cost.

Shutdown and what came next

About ten months after launch we had to tell users the service was ending. Leadership had debated direction and survival for a long time; the decision landed just before Chuseok, and we heard after the holiday. To soften the blow, the CEO met the team and walked through how we had reached that point. Anyone who had not yet had a salary review was assured this would not affect negotiations—RIDI negotiates on each employee’s hire anniversary.

We rebranded as the “account” team and started planning something new. We took the bookstore team’s purchase-list feature and would grow account-related capabilities over time. The purchase list was being redesigned from scratch, so design alone took a long while.

Resigning

Around the shutdown and my move into the new product, I was edging toward burnout. Letting go of a service I cared about stung, and I wanted a long break. I also started thinking about changing jobs again. As engineers accumulate years, many drift toward either domain-heavy or technology-heavy tracks. On Ridistory I felt I was on the domain engineer path: less deep-diving on pure tech than mapping real-world problems into systems. I had questioned for a long time whether that fit me. I missed the more infrastructure-flavored work from my previous company. RIDI had been great—thoughtful code, greenfield service, aggressive tech choices, excellent peers—but something personal still itched. As I thought harder about my career, I decided to quit.

I resigned without another job lined up—usually you secure the next role first, but I wanted rest more than a new gig. After about six years of work I felt I deserved something like a sabbatical. I left RIDI and took four months off. I studied at the library, road-tripped the country with my wife, did some ride-hail driving with a friend for pocket money, and got into fishing. When I felt restored, it was time to go back.

Back to work

I chose carefully. I focused on job descriptions more than company names—whether the work would help my career and whether I would enjoy the challenge. I steered away from postings that were generic web work or domain-first. Few listings matched. One that did was SK C&C: building a cloud monitoring service. It aligned with what I wanted. I applied, got an offer, and I am still there.