Thank you for saying I'm good at writing. I'd like to add one thing.

ChatGPT wrote most of the text itself, and Claude also helped by reading drafts, reviewing them, and pointing out parts that needed revision. My role was to set the overall direction, incorporate my experience, make necessary corrections and edits.

To put it simply,
the events and subject matter are based on my experiences, ChatGPT is the writer, Claude reviewed it, and I edited it.

Back to an Era Where No One Knew

Chapter 4

When I first entered the company, there was a computer and a phone on my desk.

And there were a lot of books.

Mine were there, and also books left behind by the person who sat there before me. Java. Oracle. Unix. JSP. Servlets. JavaScript. Just looking at the names on the spines, it seemed like a pretty great developer had been there.

In reality, I hadn't even read half of them properly.

About a week after I started, the team leader came to my desk.

He was holding a book.

The cover was thick and the title was in English.

The team leader put the book down on my desk.

Thud.

“Have you used this?”

I looked at the cover of the book.

It was a name I'd never seen before.

“No.”

“Me neither.”

The team leader said nonchalantly.

“We have to use this for our next project.”

I looked at the book and then back at the team leader.

“What are we supposed to make?”

“Member functions.”

“Member functions?”

“Sign up, log in, edit information, that kind of thing.”

That seemed to be the extent of his explanation.

I waited a bit.

It seemed like he was going to say more.

But he just stood there looking at my face.

Finally, I asked.

“Are there any similar existing projects?”

“No.”

“What about the design?”

“We'll figure it out as we go.”

The team leader left those words and went back to his desk.

I opened the book.

I started with the table of contents.

The first few chapters were about installation.

Then came examples.

Then settings.

Unfamiliar words kept appearing.

I wrote the words down in a notepad.

I read the book all afternoon.

More accurately, I wrestled with it.

I hadn't really understood much of it.

The installation didn't go well from the start.

The screens in the book and on my computer were different.

The menu locations were slightly off, and the versions seemed different too.

After about an hour, I asked the senior developer next to me.

“Have you ever tried installing this?”

The senior developer looked at my screen and said.

“No.”

“Then do you know why it's not working?”

“I don’t.”

He looked back at his monitor.

I felt a little disappointed.

A while later, the senior developer looked back at me and said.

“If it doesn't work, try lowering the version.”

“Why?”

“The book is old.”

He was right.

Lowering the version made it install.

I felt like that was a pretty big discovery that day.

A few days later, there was a requirements meeting.

The meeting room was just a room with a long table.

A planner came in with a piece of paper.

An A4 sheet with the screen hand-drawn on it.

ID. Password. Name. Resident registration number. Address.

There were a few buttons drawn.

“You sign up here.”

The planner said.

“Click this button to complete registration.”

I asked.

“What if the ID is already taken?”

The planner thought for a moment.

“It shouldn't be duplicated.”

“So, are we checking for duplicates here?”

“That seems like a good idea.”

I wrote it down on paper.

“How many times can I enter the wrong password?”

“Why?”

“Because if you keep entering it wrong, we have to block it.”

The planner glanced at someone else.

Everyone was quiet.

Someone said,

“Let's just make it so that you can log in for now.”

The meeting ended like that.

On the way back, my senior said,

“Don't ask too many questions.”

“Why?”

“Because those people don't know either.”

I laughed.

It was hard to tell if he was joking or serious.

For several days, I made the membership registration screen.

I made the screen, created database tables, and saved values.

Once the membership registration was done, I also made the login.

Once the login was done, I also made the information modification.

I made one after another.

At that time, I didn't think about the entire system first.

At least, I did.

What was important was whether the screen in front of me worked.

Whether it moved to the next screen when a button was pressed.

Whether the data was saved.

Whether the same value came out when it was called up again.

If it didn't work, I printed the output statement.

To see if it got here.

What the value was.

Where it died.

I wrote "log" too, but what I thought of as a log at the time was a little different. It was more about checking how far the execution had progressed by putting one number on the screen.

1

2

3

If the number 3 came out and 4 didn't, the problem was somewhere in between.

That was enough.

Once, I couldn't catch one error past midnight.

The data came in for sure, but it didn't save.

The query seemed right, and the connection was alive.

I looked at it for hours.

In the end, there was one missing parenthesis.

When I found it, I shouted.

“Found it!”

My senior, who was eating ramen next to me, asked,

“What is it?”

“A parenthesis.”

“Shit.”

My senior laughed.

I laughed too.

That day, we left work past 2 a.m.

The taxi fare was paid by the company.

The next day, the team leader asked,

“Did you stay late yesterday?”

“Around 2 a.m.”

“Really? Good job.”

That was the end.

Strangely, I took his words as praise.

Not long after, a problem arose with the project.

Data had to be exchanged with an external company, but the format didn't match.

The team leader called me.

“Call them and ask.”

“Me?”

“You're the one making it.”

I received a piece of paper with the phone number.

The other person was also a developer.

It was my first time talking to someone on the phone.

“Hello. I'm calling about data linking.”

I thought I had to pretend I knew what I was doing.

I didn't know what the other person would say.

Within a few minutes, an unfamiliar term came up.

I answered "yes" momentarily.

After hanging up, I wrote down the word on paper.

Then I looked for a book.

It wasn't in the book either.

I searched the internet.

There was hardly any Korean data.

I opened a few English pages.

It took me a long time to read them.

I didn't understand everything.

Still, I found the necessary parts.

I called again.

“Is this the way you mentioned before?”

“Yes, that's right.”

At that moment, I felt a little relieved.

It was more important to be able to continue the conversation even in a state of not knowing than the fact that I understood.

That happened repeatedly.

When something new came up, I bought a book.

I wrote down any unfamiliar words.

If something didn't work, I stayed up all night trying to figure it out.

No one told me the whole picture.

There wasn't a neatly organized design document coming down from somewhere either. Sometimes there were documents, but they were different from what we actually had to make.

Then I just made it and adjusted it as I went.

I could fix it later.

If there was a problem while fixing it, I fixed it again.

That's what I thought development was.

A few years later, people started talking about design more often.

I also heard the word "framework" frequently.

The word "standard" also appeared.

Someone talked about development methodologies.

Every time I heard that, I felt a little strange.

It seemed like there was always a name for what we were doing.

At the time, we just did it.

We had to do it.

If I didn't know how to do it, I looked in a book.

If it wasn't in the book, I asked someone.

If they didn't know either, I tried it.

And then I went back and did the next thing.

I don't think I was particularly brave during those times.

There was just no other way.

We couldn't stop because we didn't know something.

The company didn't know, the team leader didn't know, and I didn't know.

But we knew the deadline.

That was probably the most certain thing about development at that time.