Reflections on Five Years at LINE Fukuoka (now LY Corporation)
Introduction
Late December 2024 marked my last working day at LINE, followed by paid leave taken through the end of January 2025. This post is based primarily on my personal feelings and experiences at the time. All perspectives stem from my own role and journey, and may not necessarily reflect the current reality.
Why Japan?
I once wrote on another blog about my motivation for learning Japanese and how my journey unfolded. If you are interested, check out:
During university, the idea of living in Japan crossed my mind. However, my financial situation was tight at the time, leaving me without enough savings to fund a working holiday. My academic grades weren’t good enough for an exchange program either.
Delayed graduation combined with mandatory military service made leaving Taiwan difficult. After receiving my enlistment notice in September 2018, I was drafted for four months of military service.
Back then, I hadn’t really thought about working in Japan, let alone working there as a software engineer. It was Denny who suggested that instead of coming on a working holiday, it made more sense to find a full-time job with guaranteed two-day weekends and paid time off. That sounded reasonable, so I decided to look for a job in Japan right after finishing my military service.
I chose LINE for several reasons:
- The chance to collaborate with developers from all over the world
- The desire to take on the challenge of working in a larger organization
- No fixed working hours
- None of the traditional Japanese corporate (JTC) culture
Preparing for Interviews in Japan
Because I loved Japanese, before coming to Japan I ran a newsletter called “Japanese Greengrocer (日語八百屋)”. I wrote around 50 to 60 issues before discontinuing it. During that time, I took the JLPT N3 and N2, and passed N1 while serving in the military. Compared to those who only start learning Japanese after moving to Japan, going in this order felt quite different.
Before coming to Japan, I had already accumulated several years of development experience and regularly wrote technical articles. Given the hiring market at the time, this helped me get an interview ticket for LINE. Around 2018–2019, LINE Fukuoka was actively recruiting in Taiwan. Since Denny happened to work there, I asked him for an internal referral once my four months of military service ended.
AI has rewritten the rules of software engineering interviews, so my experience back then likely doesn’t match today’s landscape. Take it purely as historical context.
As for compensation, the listed minimum annual salary was 6 million JPY (at an exchange rate of roughly 0.3 TWD/JPY back then, that was around 1.8 million TWD). For that era, it was a pretty solid offer. Additionally, if applying for Backend-related roles, there was a chance to negotiate 10 million JPY or higher.
Why Fukuoka?
I first learned about Kyushu through the anime Kids on the Slope (坂道のアポロ). Later in 2018, I visited Fukuoka twice for travel and fell in love with the atmosphere. Plus, LINE Fukuoka was based right there.
For more thoughts, you can check out my one-year reflection after moving to Fukuoka:
Five years later, I’ve bought a home in Fukuoka. Now I can say with even greater confidence that Fukuoka is truly wonderful. Almost every Japanese colleague I’ve met who used to live in Tokyo has nothing but praise for Fukuoka.
A Brief Period of Commuting
I arrived in Fukuoka in July 2019, just about half a year before the pandemic began. For roughly six months, I commuted by subway to the office. One of the perks of working here was having no fixed clock-in/clock-out system.
I still remember the outbreak around February 2020. The company announced indefinite remote work, and Japan essentially closed its borders for two to three years before reopening to tourists.
(Here is a photo from late 2021 on my flight back to Taiwan, with fewer than ten people on board.)
During the Pandemic
From Japan’s implementation of border control measures in 2020 to their lifting in April 2023, that period felt almost compressed in time. Looking back, it was mostly working, clocking off, online nomikai (drinking parties), and occasional walks outside. But it gave me time to explore other interests: learning electric guitar, tinkering with IoT, starting a YouTube channel (though long abandoned), and even getting into gaming.
Also thanks to the pandemic conditions, both my Highly Skilled Professional visa and Permanent Residency application were approved in an unusually short amount of time.
What I Did at LINE
Here is a summary of some of the more interesting things I worked on at LINE. Naturally, there was plenty of day-to-day work (creating tickets, debugging, building features, etc.), but I’ll highlight a few notable ones.
LINE’s infrastructure runs on a private cloud called Verda. Think of it like AWS: not quite as feature-rich, but with enough building blocks to support complete web services. For example:
- Computing
- Load Balancer
- Lambda function
- K8S
- Storage & CDN
- Database
Two services stood out to me in particular:
- A solution similar to Cloudflare Images: Services centered on web and apps inevitably handle multimedia operations—cropping, resizing, converting to .webp, blurring, etc. Doing this inside the application layer quickly creates bottlenecks at scale, and LINE happens to operate at massive scale. This tool was fantastic; it saved backend engineers an enormous amount of work.
- Central Dogma: A distributed configuration management service designed to achieve high availability and eliminate the need for server restarts or redeployments when updating configs. Its dashboard uses Git-like version management, and configuration changes can be propagated to servers via pub/sub. Simple on the surface, but exceptionally useful.
I won’t dive too deeply into LINE’s overall tech stack, but it was largely the full Apache suite: Kafka, HBase, Cassandra, Airflow, with different selections tailored to each service’s specific characteristics.
Slackbot
In my first project, our deployment mechanism involved updating git tags on the backend. The company provided an internal PaaS-like tool that hooked directly into internal GitHub for one-click deployments. So I built a Slackbot for release management. Through Slack, you could trigger deployments directly, reducing the multi-step release process down to a single command.
This was during the Hubot era. For reasons I no longer recall, Hubot didn’t fit our needs, so I built a TypeScript-based Slackbot from scratch. Slack messages are constructed via JSON, so describing them in JSX-like syntax was very intuitive. For this, I referenced slack-blockx by my former colleague Kai.
Essentially, it consolidated a release flow that previously required jumping across multiple systems into one Slack command:
@hubot release beta my-org my-repo main v1.2.0
Under the hood, it verified version numbers, created tags, generated releases, and posted the commit diff back into the channel as a changelog. The commands themselves were pluggable: each command was an object, and even access control (“who can use it, in which channel”) was declared declaratively and intercepted before dispatch:
const deploy: Command = {
name: 'deploy',
command: /deploy (alpha|beta) ([^ ]+) ([^ ]+) ([^ ]+)/,
isAuthedUser: isMember, // 只有 member 能觸發
enableChannels: channelIsValid, // 只在特定頻道生效
action: async (matches, message, client) => { /* ... */ },
};I deliberately modularized the framework, splitting each command into separate files instead of bundling everything into a massive function filled with if/else statements. I was also quite adamant about testability. The biggest hassle with Slackbots is having to connect to Slack and send real messages every time you test, which makes feedback cycles very slow. I abstracted the Slack communication layer into a class, completely isolating command logic from the Slack SDK, and even built a terminal adapter so I could test commands directly in the local terminal without ever opening Slack during development.
Looking back, I feel a bit nostalgic. Today, you could probably hand this entire architecture and codebase to an AI and get it done in a single day—or rather, instead of constraining AI agents with code, you’d just prompt them on what to do.
Improving the Deployment Environment
At the time, we had multiple features under simultaneous development for a single service. Team members were split across projects, but sharing the same codebase meant QA testing often collided. With a limited number of test environments, another colleague and I used nginx cookies to inspect which branch a user was on and route them accordingly. During that period, I learned a tremendous amount of Ansible from a Taiwanese colleague I worked closely with, and I’m deeply grateful for his patient, hands-on guidance.
However, switching cookies was tedious and unintuitive. Later, another colleague took a much bolder approach: combining Envoy and Docker integrated with GitHub, allowing every push to automatically update the deployment and dynamically assign a domain. This comes out of the box on PaaS platforms like Vercel, but pulling it off inside an internal private cloud was no small feat.
Landing Page SSR
A certain financial service needed a customized landing page launched, but internal tooling at the time could practically only serve static images (many Japanese web services are just full-page images built specifically for mobile screens). Other teams on the same project had already adopted Next.js, while ours was still a pure SPA with a Node.js server. Bound by our architecture, we could only serve static assets without running dynamic server-side rendering, so I started pushing for SSR adoption.
Looking back, championing SSR without Vercel in a large organization was an uphill battle. Just provisioning servers required negotiating resources with the SRE team. My project-advocacy skills weren’t mature enough yet, and my former Engineering Manager helped me tremendously. I drafted clear architecture diagrams, implementation plans, and objectives to communicate with SRE, and only then managed to secure production servers. The development and QA environments had to be sorted out on our own, which included brute-forcing my way through Ansible.
That was my busiest year, and the one where I learned the most. This SSR setup was subsequently reused for other features—the upfront build was just as demanding, but as our shared component library grew, it saved more and more time down the line. It also delivered tangible results for the SEO visibility that the planning team was always emphasizing.
Sentry Automation
Since this was a FinTech product with ample resources, we spent substantial time on performance optimization. Sentry had just rolled out Core Web Vitals at the time, offering visibility into web performance metrics in the dashboard. I integrated Sentry’s API to build an automated notification system that posted daily reports to Slack.
Internal Tools on K8S
Throughout our development workflows, there were numerous small processes ripe for automation. While LINE had standard development guidelines, practices still varied depending on the team and service. For example:
- Whose turn it was to facilitate the daily standup this week
- Automatically updating JIRA ticket status once a PR was merged
- Slackbots
The issue was that deploying any internal tool created a dependency on that specific author, making it hard for anyone else to jump in and contribute improvements. Since our internal platform already allowed spinning up K8S clusters, a colleague took the initiative to build a shared platform. Any internal tool could be deployed into K8S, so developers only needed to commit code while CI handled the deployment.
LINE Securities (LINE 証券)
I served primarily as the frontend Tech Lead for Tsumitate NISA (つみたて NISA) and credit card investment (クレカ投資) integration with NISA. Around that time, the frontend team underwent organizational reshuffling, bringing in two Japanese engineers and one French engineer. All of them were exceptionally capable and helped me a great deal. The French colleague had a very distinct personality—he loved gaming and anime, and we always had endless topics to chat about.
When I first joined, the team was mostly new graduates who were much younger than me, but shockingly talented, including several active open-source contributors. We held regular weekly sessions to exchange technical knowledge.
Even though it was a financial service, the team aggressively adopted modern tech like React and Kotlin (on the backend). It was obvious that people genuinely loved technology rather than treating it merely as a job in finance.
For instance, when React first introduced Recoil, our team adopted it almost immediately. While questioned for being overly bleeding-edge, the decision was ultimately approved. In a different team, the exact same proposal might have played out entirely differently.
Similarly, to let frontend engineers integrate before backend APIs were ready, the team introduced libraries like msw for easy mocking. To keep the UI stable, Cypress was integrated into CI for E2E testing early in the project.
Unfortunately, this service didn’t go the distance. LINE Securities transferred its securities business entirely to Nomura Securities in August 2024, marking the end of the line. Seeing something you poured effort into get decommissioned always leaves mixed feelings.
Impression-Based Feed Ranking
In my later days at LINE, I had the chance to transition to backend work, taking over an impression-based ranking mechanism for a feed that tracked which content users actually viewed. It sounds straightforward, but this service had tens of millions of MAU. At that scale, every naive approach turns into a backend-crashing landmine. The feed used server-driven UI: the screen wasn’t hardcoded in the app, but dynamically rendered based on a JSON contract returned by the backend. The tradeoff was that every single impression had to report back to the backend.
The most intuitive approach—“send an API call whenever a user views an item”—would easily bring down the backend under such traffic volumes.
So we shifted to having the client emit Kafka events directly, cleanly decoupling the write path from the serving path. Deduplication and ranking were offloaded to Redis Sorted Sets, using timestamps as scores with a 24-hour TTL so expired entries dropped off automatically.
Unfortunately, this design never made it to production—it was still in testing by the time I left.
Hackathons
The company hosted hackathons almost every year. I took part in a few; here are a couple of projects worth sharing.
CO2 Monitoring
For full details, check out this post—a project I built alongside a Dutch colleague who was on the same project as me at the time.
The concept was using a CO2 sensor to measure concentration, connecting via ESP32 over Wi-Fi to MQTT, ingesting the data on the server side, and visualizing it with Grafana.
For technical details, you can read this article:
A quick note on the Dutch colleague I worked with on this:
The sensor I bought came with an ready-made Arduino SDK, and my initial instinct was just to plug it in and use it. But he pointed out: since we’re doing a hackathon, we might as well learn something. If we rely entirely on pre-packaged libraries, isn’t that just like what we do every day (calling APIs)? I found that convincing, so we pored over the sensor’s datasheet together and implemented the communication protocol from scratch.
A second memory was when he got stuck writing tests for a form submission (multipart/form-data) and came over to ask how to mock a form request. He understood conceptually that a form request is just a specific type of HTTP request, but wrestled with the library without success. I took a look, spotted that the form boundary hadn’t been set properly, and fixed it in seconds.
The third was when we talked about our favorite YouTube channels, and he recommended Ben Eater. For anyone who loves digging into computer fundamentals, that channel is an absolute goldmine: to explain how computer networking works, he starts right from the electrical signals on transmission lines (complete with an oscilloscope) all the way up to the application layer. He also built a functioning 8-bit CPU from scratch on breadboards.
In an age where AI continues to advance rapidly, this kind of bottom-up mastery feels increasingly rare. But regardless of the era, I believe it remains an invaluable quality.
IoT Pomodoro Timer
Another IoT project. I found Swift’s BLE API quite pleasant to work with, so I built a physical Pomodoro timer prototype: connecting to a Mac via Bluetooth, allowing you to start and pause timers from the computer while tracking statistics. I thought it was a neat idea (if I do say so myself), but since the hackathon only lasted a day and a half, I didn’t pursue it further.
Bluetooth Meeting Display
I discovered that on macOS, native calendar events can be monitored. One of my favorite menu-bar utilities, MeetingBar, uses this very concept. (Go download it so you never lose track of meetings while deep in coding.)
This meant I could write an app to broadcast these calendar events over Bluetooth to an external display. The same pattern can be extended endlessly—as long as you can broadcast whatever metric or event you want to monitor.
Manager A and Manager B
I want to dedicate some space to two managers who contributed immensely to my growth.
Manager A was Japanese and headed the entire frontend department. He was an outstanding communicator, knew how to lead teams, and excelled at navigating different personality types among developers. Although he was modest and often claimed his technical skills couldn’t match the rest of the team, he consistently stayed on top of industry developments and kept close tabs on everyone’s progress.
After getting to know him better, I realized he had virtually zero worldly worries 😂: a father of two, his wife ran a coffee shop, his savings were bottomless, and he was basically working to socialize and make friends.
Manager A played a huge role in my career development. We followed each other on Twitter, and he would quietly check in on how I was doing (in a very tactful, understated way). Whether to share personal social media accounts with coworkers is a matter of personal preference, but if I get along well with someone, I usually ask—after all, working together at the same company is a meaningful connection.
When I first joined, the culture was vastly different from my previous workplaces. I tended to obsess over technical details within the team, but my communication style was poor. I nitpicked colleagues’ proposals, which often made me come across as domineering and difficult to work with.
Eventually, a colleague gave me very harsh negative feedback, saying my attitude was hurting team morale—writing bluntly that my behavior made them “pissed off.” Manager A gave me a serious reminder: in a workplace, what matters most is delivering influence. Your current approach doesn’t help move projects forward; in fact, it actively derails them.
At first, I brushed off the critique, wondering why nobody seemed to care about code quality, only to get penalized for caring.
Gradually, Manager A patiently guided me to where I am today. He read widely and recommended How to Win Friends and Influence People (人を動かす). My mindset shifted fundamentally because of that book; it was the first time I realized how much mattered beyond raw technical skills. From that point on, in addition to technical books, I read heavily on management and interpersonal communication.
The other manager, Manager B, was an Engineering Manager on the same project. He was also brilliant at team building. Though we only worked together for a brief year, it was because of Manager B that cross-team negotiations, back-and-forth alignments, and resource requests were handled smoothly.
We had a great rapport. When I mentioned I was translating some of my older blog posts into Japanese, he offered without hesitation to review and polish my drafts. After I solved a tricky project issue, he even bought me a Nezuko figurine as a gift.
Later on, I’d occasionally play Splatoon 2 with him and his daughter. When he heard I wanted to build a new desk, he drove me to the home improvement store (ホームセンター) to pick out lumber.
After project reshuffles, I came to realize how vast the differences between managers can be. How much they care about the team, and whether they shield their reports from friction, vary wildly. On one project, the manager barely showed up outside of meetings; on Slack, questions either went unanswered or were met with late-afternoon replies right before the end of the day.
A manager is vital to a team because they don’t just set the example—their working style directly shapes the team’s working style. When a manager demonstrates indifference toward timelines or quality, it signals to everyone under them that timelines and quality don’t matter.
Looking back, most managers I encountered earlier in my career were exceptional, which made running into mediocre ones quite disappointing. But it was also a grounding reminder of how the real world operates.
Memorable Moments
Happy Friday
Back then, the last Friday of every month was Happy Friday. The company provided light snacks and drinks, and everyone gathered in the Cafe Space to chat. It stopped after the pandemic hit, and I still miss those days.
There was also a weekly all-hands company meeting on one afternoon. After general announcements, the remaining time was usually reserved for:
- Self-introductions for new joiners
- Open slots for lightning talks on any topic
It was a great venue to hear about problems faced by other projects and their solutions, as well as an opportunity to connect across teams. On Fridays, the frontend department also had its own knowledge-sharing sessions.
Business Trip to Korea
In late 2019, the company held the UIT Global Workshop, bringing frontend engineers from Japan, Thailand, Taiwan, and Korea together at NAVER’s Connect One in Korea.
Connect One is located in Chuncheon, South Korea, built specifically as a training facility for NAVER employees. It boasts diverse office spaces, meeting rooms, auditoriums, and surprisingly upscale accommodations.
The official schedule mostly featured case studies of frontend architectures applied in real production products. The rest of the time was spent sharing meals, networking, and getting to know engineers from different countries.
LINE Developer Day 2019
Shortly after, there was another conference: a company-sponsored trip to Tokyo for LINE Developer Day 2019. I documented my reflections in two posts: Part 1 and Part 2: Slack Rewriting Search with Armeria.
My biggest takeaways from the conference were:
- Discovering that LINE had created an open-source microservices framework called Armeria, which was even used by Slack
- Seeing practical applications of BERT in production environments
Why I Left
Leaving wasn’t triggered by a single incident; it was more like several threads converging on the same conclusion over time.
Fundamentally, working in a large corporation makes it hard to break out of established molds. Climbing higher was certainly possible, but my awareness wasn’t there yet—I hadn’t fully grasped the rules of the game. At the same time, I felt my career hit a plateau. On top of that, two consecutive services I worked on were sunsetted, which meant that on paper, my measurable impact was essentially zero.
Management was another factor. Managers I worked with later in my tenure felt like NPCs: when presented with problems, their feedback was generic, and I didn’t get the sense that they were invested in the team. 1-on-1s felt like going through the motions to check off daily administrative duties. This became even more pronounced after I switched to the backend, where one manager and I frequently had friction and differing views.
On my final project, the product was heavily business-driven, often leaving me feeling like I spent weeks just to push out a minor feature. The redeeming part was having the chance to work on backend engineering. Transitioning to the backend taught me a great deal about handling high-throughput systems, and I was responsible for designing a recommendation system. Sadly, it was still in the testing phase when I left, never reaching production. The project also increasingly revolved around optimizing for ad impressions, which left me feeling more and more aimless.
What bothered me even more was the logic behind promotion-driven engineering: Goodhart’s Law—when a proxy metric becomes the target, it ceases to be a good metric.
I saw plenty of low-value initiatives wrapped up as high-impact accomplishments. For example, there was an internal push to standardize configurations across teams, which yielded a shared configuration repository. But once the spotlight faded, it was neglected. The configs fell into disrepair, couldn’t adapt to individual project needs, and teams went right back to managing their own setups.
Eventually, I made peace with this dynamic. Even if something lacks value, you need the skill to articulate why it lacks value. And if something mediocre can be packaged from a 60 to a 100, it means that if you believe your work is worth 100, you have to package it as 200 just for it to be recognized.
In large organizations, many contributions can’t be neatly quantified, so management defaults to metrics and slide decks. To be clear, failing to play well within established rules was entirely my own shortcoming. I neither changed the rules nor placed on the leaderboard under them.
The final catalyst was AI. 2024 was the breakout year for LLM models. Inside a large enterprise, adopting AI unavoidably brings compliance, security, and data governance hurdles, making it difficult to experiment freely with state-of-the-art models.
I believe AI will shape the next several years, bringing profound shifts to software engineering, and I wanted the freedom to explore it without constraints. After agonizing over it for a long time, I made the call to resign. It was a tough decision because it meant stepping into total uncertainty, but looking back, I am glad I took that leap.
Regrets
My interpersonal habits were deeply shaped by my background. I rarely initiate contact, I’m not a natural socializer, and I generally prefer solitude.
Consequently, I didn’t proactively build relationships beyond my immediate project teams—whether with non-engineering departments or developers on other projects. I simply didn’t understand the importance of it back then.
Once remote work became the norm after the pandemic, spontaneous opportunities to connect vanished, which was a real loss. The result was leaving the company feeling quite isolated; turning in all my equipment left a hollow feeling that stung.
A few minor regrets worth mentioning:
- A colleague was from Australia and mentioned it early on, but I somehow misremembered and assumed he was from the UK.
- When talking with a French colleague, I asked, “So, have you learned how to use chopsticks yet?” In hindsight, that was pretty rude—it presumed that because he wasn’t Asian, he naturally wouldn’t know how to use chopsticks.
Another incident weighed on me more heavily: a conflict arose between coworkers, and I chose to stay silent. In my eyes, the issue itself wasn’t catastrophic, but my perspective never reached the person involved.
Looking back, the emotional stress they bore must have been significant. I tend to react to uncomfortable situations by withdrawing. But if you want to grow into leadership, uncomfortable conversations are unavoidable; in fact, uncomfortable conversations are often the job itself. It happened long ago, but it has stayed with me ever since.
Later, I managed to share a farewell meal with the teammates I had worked with the longest, and I’m deeply grateful to them.
Lessons Learned
The company offered me unprecedented opportunities for growth: designing scalable architectures under massive traffic, provisioning servers from the ground up, collaborating with developers from across the globe, aligning across cross-functional teams, and leading feature deliveries. These were priceless experiences. It takes that level of traffic and scale to even encounter problems you would never have thought about before.
- Technical chops are a weapon, but not the whole battle. Especially in delivery, LINE had standardized many workflows. Smooth execution was often the result of managers smoothing things over behind the scenes, rather than my own doing.
- To expand your influence, you must deal with people. At LINE, I learned processes, documentation, and software engineering methodologies, but when it comes to “people,” I still have a long way to go.
You can find more reflections on this in my Career Retrospective.
Closing Thoughts
Whenever working in Japan comes up, skepticism is common: lower salaries, high taxes, conservative corporate culture, and so forth. Every company has flaws, and LINE certainly had its share. Still, I wholeheartedly recommend anyone who gets the chance to experience working in an organization of this scale.
Personally, I love living in Japan. Taiwan is undeniably comfortable, and in terms of career ceilings, many dismiss Japan in favor of Silicon Valley—a point I actually agree with. But I simply wanted to live in Japan.
I’ve talked with many Western and Indian colleagues about this: leaving your laptop on a table at Starbucks while you go to the restroom and coming back to find it untouched, or walking down the street with your phone out without fear of being mugged—these things rarely happen in many parts of the West. Among developed countries, Japan preserves remarkable public safety and a relatively affordable cost of living.
My takeaway after leaving is to remain kind, and help others whenever you can.
It sounds like a cliché, but I’ve seen too many people weaponize technical knowledge for gatekeeping, growing more arrogant as they rise. Technical barriers will inevitably be flattened by AI; when that happens, the people who endure won’t be the ones perched on high horses, but those willing to lend a helping hand. I will always remember the night a stranger banged on my door and terrified me, and a Taiwanese tech manager went out of his way to check in and make sure I was okay.
I’ll close with a few snapshots of life in Japan. I hope this post gives you some useful takeaways. And if you ever visit Fukuoka, feel free to hit me up for coffee!
Related Posts
- Baskets and Spears This story comes from one of my favorite book series growing up—the stories of *The Fifth Discipline*. As a kid, I naturally had no concept of organizations or teams; I simply loved the stories. Little did I know that as I grew up, I'd realize these stories were entirely about teams.
- 15. A Life Full of Gratitude Growing up, my family wasn't well-off, and life wasn't easy. Without financial support, your choices become very limited. Yet in an environment like this, I still...
- 14. 1,000 True Fans This concept is a business strategy for creators (such as artists, writers, musicians, and makers). It argues that creators do not need to become global superstars or amass millions of followers; they only need a dedicated group of loyal supporters to make a steady living and sustain their creative work.
- 13. Embracing Uncertainty Nassim Taleb, author of *The Black Swan*, once introduced a concept: events that seem utterly impossible happen when we least expect them, and for the most part, we cannot predict them—yet they carry an immense impact. COVID-19 in 2020 was the quintessential example: the pandemic completely transformed the way people live and work, and countless businesses folded under the strain, with things only beginning to turn around in 2023.