SK C&C (Jul 2018 ~ )
A fresh start
On day one I saw an office with empty desks. Later I learned it was summer vacation season and many people were away—including my group’s lead. For the first few days I picked up a laptop and got used to systems and atmosphere.
When my lead returned, I got a proper briefing: our stack, goals, and how the group fit together. The architecture was almost entirely new to me. Relational databases were used mostly for small, meta-style data; InfluxDB carried the heavy time-series load. The TICK stack sat alongside Kafka, Kubernetes, and other tools I had never touched. I researched and asked colleagues until I could picture the whole platform. It was a lot to absorb, but that was the job, and as an experienced hire I needed to become productive quickly.
Learning the stack was not only hard—it was genuinely interesting. Generic web architecture has plenty of references online; time-series systems less so. Kubernetes was becoming the de-facto orchestrator, and I already wanted to learn it. Field work—figuring things out hands-on—was the best teacher, and I enjoy new tech, so onboarding was oddly fun.
New languages
I also picked up new languages. Go, which had been a hobby, became production code. The problems we tackled benefited from Go’s concurrency model, and Java would have felt heavy. I used Go widely: batch jobs, small API servers, metric collectors, and agents.
TypeScript arrived when we needed a simple internal back office. At first I used JavaScript with Koa on the server and React on the client. As features piled on, I kept hitting language limits and looked at TypeScript. After syntax basics and a tiny toy project, I was convinced we should adopt it—aside from the learning curve, there was little reason not to. We ported backend and front end to TypeScript and ended up with stabler, easier-to-maintain code.
I also looked at NestJS as a Koa successor. Express had dominated Node servers; it still shows healthy npm trends, but to me Express feels more like a library than a framework—no special advantage at scale. I preferred Koa over Express, but Koa had clear limits and lukewarm momentum. With TypeScript I discovered NestJS—it felt like a next-generation framework compared with Express or Koa, and a toy project confirmed the ergonomics. We never rolled it into production: rewriting legacy for incremental gain was a hard sell, and I was not confident I could convince the team. For a greenfield TypeScript service today, I would pick NestJS without much hesitation.
Open-source contributions
Here I made my first code contributions upstream. We leaned on the TICK stack and knew Telegraf, the metrics agent, down to the source.
Once, Windows install failed to start. Troubleshooting showed the default config was wrong—a few-line fix. I opened a PR and it merged. Since I already lived in the Telegraf codebase, I decided to keep contributing. The issue tracker had hundreds of open items; I started with small bug fixes and eventually shipped feature PRs.
One feature PR felt especially good: Telegraf release notes credit contributors by GitHub handle next to what they added—my username showed up when that release shipped.
The best part of contributing was leveling up unit testing in Go. Telegraf will not merge PRs without tests for new code, and maintainers ask for more coverage when needed—so I had to write tests seriously.
Tech soft-landing
New teammates joined and worked on code I had owned. One newcomer had no web background, which made our Node.js + React (ES6) codebase hard to parse. That ecosystem grew through trial and error; even with the same stack, coding styles and baseline knowledge diverge, and peripheral concepts are scattered. I imagined how confusing that must feel on day one.
Node demands async work; the patterns evolved from callbacks through generators, promises, and async/await. Our code favored async/await, but you still need some grasp of promises and callbacks. JavaScript mixes imperative and functional styles, shorthand like destructuring, var / let / const, null vs undefined, == vs ===, CommonJS vs ES modules—beginners drown. Add npm, Babel, browser compatibility, and it is overwhelming. Each piece is learnable, but the real question for newcomers is “how much of this do I need, and from where to where?”
To ease the ramp, I prepared ten staged assignments: start with a Node “hello world” server, then ES6, REST and layering, light clean-code habits, ORM-backed DB access, TypeScript migration, Docker image build, and Kubernetes deploy. Tasks lived in GitHub Issues; we reviewed and merged via pull requests.
Per stage I listed goals, split concepts into “must know,” “nice to know,” and “skip for now (revisit later),” and stated how deep each topic needed to go. Easy-to-google topics got search keywords; obscure ones got prose; huge topics got summaries plus pointers for deeper reading.
I also stressed why: why we chose a technology, why the code looks a certain way. I nudged people, when studying anything new, to ask why it exists and how it compares to alternatives—useful when hype cycles churn daily and you need to tell signal from noise.
Digging into Kubernetes
Before this job I had only heard of Kubernetes and friends; Docker was the extent of my container experience, and even that was self-study. When I joined, Kubernetes was not in the stack yet—everything ran on IaaS VMs. Then Kubernetes arrived; less critical services moved first, and most of our services now run on clusters.
My code deploys to Kubernetes, but I would not claim deep expertise. I have read the official docs repeatedly and only feel how much further there is to go. People call it the new OS of cloud native; it is on my list to go deeper.