02. My Introduction to Computers: The Long Way Back to Software Development

Whenever I heard a key turning in the front door, I would immediately pull the plug on the computer, hoping to make it look as though I had not touched it all day.

My introduction to computers began in the late 1990s. There were no lessons and no clear goals—only a computer that could not hide its residual heat, and a child who always wanted to open it up and see what was inside.

The trick never worked. The computer case stayed warm, and the CRT monitor would make a few telltale creaking sounds as it cooled down after being switched off. If I waited until my parents were already inside before cutting the power, there was little I could do except admit defeat.

And yet, the next time they went out, I would turn it on again.

When the Key Turned in the Door

As a child, my interest in computers was not particularly technical at first. I mostly wanted to play games. On weekends, I would wait for my parents to leave, sit down in front of the computer, and stay there until I heard their key at the door. Then I would scramble to erase all evidence of what I had been doing.

But games were not the only attraction. Sometimes I took the components out of the computer case and tried to put them back together. When the operating system stopped working, I found a Windows 98 CD and reinstalled everything.

I had no particular objective. I was curious, and computers of that era provided no shortage of excuses to experiment. Operating systems were far less stable than they are today. A computer could freeze without warning, and the next time it started, Windows might refuse to load altogether.

Frequent failures gave me frequent reasons to tinker.

While many children around me were still learning how to open programs and launch games, I had begun using MS-DOS commands. I was willing to enter an English-only BIOS, adjust hardware settings, and even attempt to overclock the CPU.

Looking back, I doubt everything I did was correct. My confidence probably exceeded my knowledge. At the time, however, I did not know enough to be afraid.

Most of what I learned came from computer magazines. My parents gave me enough pocket money to buy the popular publications of the time, and I followed their articles step by step.

I have forgotten many of the details, but the method stayed with me: encounter an unfamiliar term, find somewhere I can experiment with it, and try it myself.

I Thought Dreamweaver Was a Game

In the late 1990s, the computer mall was practically the only place in our small city where people could buy home computers, components, and software. I loved wandering around there, looking at hardware and browsing rows of pirated game CDs.

Buying those discs felt a little like opening a mystery box. To make full use of the available storage, sellers often packed several games onto one CD without listing everything on the cover.

I would buy several discs at once, install every game when I got home, and then return to the seller with an excuse to exchange them for something else. Sometimes my classmates and I traded discs with one another. Games spread from person to person through physical media—a slower, more social precursor to the BitTorrent downloads that came later.

Around 1998 or 1999, when I was nine, I received a disc from a classmate. Alongside the game I wanted were two unfamiliar programs: Dreamweaver and 3ds Max.

I had no idea what they were. I assumed they were games and installed both.

After opening Dreamweaver, I clicked around until I produced a basic page. Then I noticed another window where I could edit code. I typed random characters on the keyboard, and the content immediately appeared on the page.

I did not know it was a web page. I did not understand that I was looking at code. I only found it strange and exciting: what appeared on the screen was not fixed. I could type something in one place and watch another part of the screen change.

Years later, at university, I saw older students using Dreamweaver for their graduation projects. Only then did I understand that the mysterious program I had opened at nine was a web editor.

3ds Max was even harder to understand. I spent a long time investigating its buttons before discovering the built-in 3D teapot, which I could move, rotate, and reshape.

For a while, I believed that if I adjusted the teapot correctly, the real game would begin.

It never did.

The software was in English, and computer magazines rarely explained professional tools like these in much detail, so I eventually stopped exploring. The idea that I might have taught myself C++ at nine if only I had understood English is, of course, the adult version of me exaggerating on behalf of my younger self.

Still, that disc left something behind. For the first time, I saw that computers were not only machines for running games made by other people. They could also be used to change pages, create graphics, and make things that had not existed before.

Moving Further Away from Computers

My childhood interest in computers did not turn into a clear career plan.

I studied computer science at university in China. When I later moved to Japan, I originally intended to continue in the same field.

Reality disrupted that plan. I did not have enough time to review the science subjects required for the Examination for Japanese University Admission for International Students, so I chose the humanities track instead. My score was low, my choice of schools was limited, and I eventually enrolled in a business program.

After graduating, I followed the direction of my degree and joined an accounting firm.

None of this resulted from a carefully designed plan. At each stage, I chose from the options still available to me and kept moving.

I joined the accounting firm in 2015 and quickly discovered that I disliked spending every day working with numbers, spreadsheets, and financial reports. Whenever I imagined doing similar work for the next several decades, I felt restless.

After five months, I resigned.

I had no new job and very little savings.

Those few months of employment had not left me with enough money to support myself for long. I reduced my expenses wherever possible. If I could get through a day on one meal, I did not eat a second one.

That sounds like a story about surviving through willpower. In reality, I eventually asked my parents for money, and their help carried me through the hardest months.

Leaving accounting did not reveal a new direction automatically. I knew what I did not want to do, but I had not yet proved that I could do anything else.

At Least There Was Some Water in the Bottle

Around 2015, Japan’s software industry had plenty of open development positions. Even without professional engineering experience, I managed to get several interviews through recruiters.

Most ended after the first round.

The reason was straightforward: I had no development experience and no projects to show. Fragments of technical knowledge collected from blogs were not enough to convince an interviewer that I could do the work.

To find another job, I began studying Java, SQL, and PHP. I found freeCodeCamp and Khan Academy online and followed their courses.

I studied for less than three months. I did not complete a single project that I could present to an interviewer, and I was nowhere near fully prepared to become an engineer.

The internet offered countless free tutorials and stories about people who had successfully moved into software from other industries. Those stories could feel like motivational soup, but during periods when I struggled to keep studying, they occasionally gave me enough energy to continue.

After a while, I still could not say how much I knew. The best description was that an empty bottle finally contained a little water. When I shook it, at least it made a sound.

“Come Tomorrow”—and My Three-Week Delay

I eventually applied to a staffing company on my own. The person who interviewed me was a solution manager who would later give me my first opportunity in software development.

He asked, “Do you have any development experience?”

“I built a blog by hand,” I said. “I also deployed a LAMP stack in a virtual machine by entering all the commands myself. And I know a little Java and SQL.”

“What kind of development do you want to do? Backend services, mobile apps, or infrastructure?”

“I don’t know yet. Writing code gives me a sense of accomplishment, though. I’d like to try web development.”

“You’re twenty-six,” he said. “That isn’t particularly young for someone entering development. You need to get started soon.”

“When should I start?”

“Come tomorrow. We’ll let you work on a project, give you some basic training, and then send you to work with a client.”

I agreed aloud, but privately thought I might still find a better job.

I did not report to the office the next day. Instead, I returned to the recruiters and attended more interviews.

Three weeks later, after confirming that I could not secure another development role, I went back to the same office. The manager asked where I had been and why I had failed to appear after promising to start.

There was no respectable explanation. I had imagined I still had better options. All I had done was collect a few more rejections before returning to where I had started.

He allowed me to stay because he believed I was willing to work for the opportunity. The company offered unpaid training in its office, with my transportation and lunch expenses reimbursed.

The arrangement was far from generous, but it gave me what I needed most at the time: someone was willing to let me begin before I had fully proved that I deserved the chance.

I entered the software industry as a dispatched worker, beginning with software testing. I left that first IT company relatively early, but I have always remained grateful to the manager who accepted me.

He did not complete the career change for me, nor did he guarantee that I would succeed. When other companies were unwilling to take the risk, he gave me somewhere to start.

My First Demo Made It to a Developer Conference

I was later assigned to Everysense, where I tested its application. I was still working as a tester, some distance away from being able to call myself a frontend engineer.

Then the company’s founder needed a data-visualization demo and asked me to build a small page that could present the data.

I used Vue for the frontend, Leaflet for the map, and Chart.js for visualization. The finished page could display GPS locations on a map and use scatter plots to represent heat distribution across data from a six-axis sensor.

The names of those tools may not matter much to non-engineers. What mattered to me was that I was no longer checking features built by somebody else. For the first time, I was turning raw data into something people could see, interact with, and present to others.

The founder later used my demo to showcase the company’s product at a developer conference.

It did not become a famous project or produce a dramatic result. But it gave me concrete evidence that I could do more than study development: I could build something useful.

That small page became my entry point into frontend engineering.

In 2016, I also created my first GitHub project, leaflet-menu, a tool for displaying a menu on a Leaflet map. It was small and had little impact, but it gave me confidence.

At nine, I had typed random characters into Dreamweaver. Now I was building my own tools around interactive maps.

Reaching Into Every Part of the System

Over the following decade, I worked across five teams. My responsibilities expanded from embedded-system testing to frontend and backend web development, data engineering, architecture, and cloud infrastructure.

Some engineers around me advised me to remain in one area and deepen my expertise over several years. That advice is sound. Long-term specialization can produce stronger and more rigorous technical ability.

For me, however, moving between roles offered a different kind of value. It allowed me to view the same software system from several perspectives.

Testing taught me how features fail. Frontend work made me pay attention to how users encounter a system. Backend and data engineering required me to consider how information moves. Architecture and infrastructure revealed how many things beyond application code determine whether a system remains stable.

Working across fields also reminded me how much I did not know.

Sometimes I bought coffee for colleagues or engineers from other teams in exchange for a little of their time. Looking back, those invitations were probably not always welcome, especially when the other person was busy. But whenever I managed to arrange the conversation, a few cups of coffee often bought access to useful ideas and experience.

Many people needed a coffee break anyway.

Without speaking to people in different roles, it is easy to mistake the part of the system you know for the whole system. Hearing someone else describe the same problem can reveal how shallow your own well is—and how comfortably you have been sitting at its bottom.

The Empty Space Left by Remote Work

That way of learning changed in 2020.

During COVID-19, the company required employees to work from home, and our conversations and meetings moved to Zoom.

Talking through a screen never felt as natural as talking in person. Some people kept their cameras off, removing facial expressions and body language from the conversation. When the network became unstable, delays and noise broke discussions into fragments. Even when the spoken content was clear, the exchange lacked some of the familiar feedback of an in-person conversation.

Over time, I adapted to working from home. I could enter a state of deep concentration early in the morning and remain there until my first online meeting. Time that had once been scattered across commuting, walking between rooms, and spontaneous conversations became larger, uninterrupted blocks.

I also began to realize that my workload was not as full as I had imagined. Some tasks could be finished in one morning. After attending several meetings in the afternoon, I could sometimes complete work scheduled for the following day.

With less social interaction, more discretionary time appeared during the day.

I used much of it to build software.

Sometimes an idea appeared without warning. I would think something ought to be possible, open my editor, and try to make it work. As a result, my GitHub account accumulated many small repositories.

Most were never finished. None became products.

Unfinished and Unsuccessful

I once found it easy to regard every unfinished project as a failure. It seemed that unless a project was released, attracted users, or remained actively maintained, the time spent building it must have been wasted.

Looking back, the situation is less tidy.

Those projects did not solve important problems, and they do not need to be repackaged as successes. Most of the repositories remain untouched. Nobody uses them, and even I rarely open them anymore.

But they still took part in my development as an engineer.

leaflet-menu never became an influential open-source project, but it gave me confidence when I was trying to move from testing into frontend engineering. Other unfinished projects played similar roles. They became starting points for ideas, places to practice programming, and rough drafts that helped me test whether an approach might work.

They did not necessarily create external value, but they changed something internally.

I have other projects, including pitayan-blog-theme, each with its own history. Those belong in another story. Trying to include every repository here would turn this account into another project list.

The point is not to prove that every project was meaningful. It is to acknowledge how I have always learned: when I think of something, I try to build it and see what happens.

My Introduction to Computers Never Ended

Looking back, my route into software was never carefully planned.

At nine, I did not know what Dreamweaver was, and I did not understand that the 3D teapot would never lead me into a game. I studied computer science in China, but switched to business after moving to Japan because of exam preparation, limited options, and a low score.

When I left the accounting firm, I had no portfolio and little development ability. When I finally received an opportunity, I failed to appear and returned three weeks late because I had imagined I could find something better.

These decisions involved curiosity and poor judgment, personal choices and practical limitations. They cannot honestly be arranged into a polished story about a child who loved computers and smoothly grew into a software engineer.

That is not what happened.

If one thread has remained consistent, it is my willingness to open unfamiliar things and try them myself. As a child, I dismantled computers and reinstalled operating systems. Later, I learned to code, moved across engineering roles, and used spare time to create repositories I would never finish.

The same impulse sat behind all of it: I wanted to understand how something worked, and I wanted to know whether I could change it.

More than a decade of engineering experience has not removed that impulse. It has only given me better methods—and a clearer understanding that an experiment may lead nowhere.

Most of those repositories never became products. The 3D teapot never took me into a game.

But from the age of nine until today, I seem to have been doing the same thing: opening something unfamiliar, trying to change it, and seeing whether I can understand why it works the way it does.