The Age When No One Knows Anymore
Chapter 5
These days, there were a lot of things to do before starting work.
Check tickets, read requirements, find related documents, create branches, write scopes of work.
Even after writing all the code, it wasn't over.
Testing, committing, creating pull requests, receiving reviews, checking security audits, waiting for deployment schedules.
In the past, a line of code that could have been fixed in the morning and uploaded in the afternoon now had to go through many eyes.
There were many good things about it.
You could see who changed what and when, and if there was a problem, you could always revert to a previous version.
In the past, someone sneaking into the production server and overwriting a file without anyone knowing was rare.
At least in principle.
I had been looking at one ticket all morning.
The content was short.
Points are not being accrued after order completion under certain conditions.
There were reproduction procedures attached.
There were also test accounts, related screen captures, and the time of occurrence.
It was incredibly kind data, something to be envied in the past.
But even after an hour, the cause wasn't visible.
The order service was processing normally.
The point service call was successful.
There were no errors in the logs.
I followed the related code.
Order completion.
Event issuance.
Point service call.
Result saved.
Everything looked normal.
A young developer next to me asked.
"Are you still looking at it?"
"Yeah."
"Did you ask the AI?"
"I already did."
"What did it say?"
"It said the code looks fine."
He laughed.
"That's the scariest answer."
"You're right."
I laughed too.
The AI suggested a few possibilities.
Transaction problems.
Asynchronous processing failures.
Retry logic.
Event loss.
Cache inconsistencies.
They seemed plausible.
And none of them were right.
I read the ticket again.
Under certain conditions.
That phrase bothered me.
"What exactly are these conditions?"
The young developer peered at the screen.
"Orders using coupons."
"All coupons?"
"No, it says a specific coupon."
I found the planning document.
There was a link.
The document was well organized.
Title.
Revision history.
Person in charge.
Related tickets.
As I read through the document, I came across a strange sentence.
For promotional coupons, the accrual policy follows the existing policy.
Existing policy.
I stared at those words for a while.
It was one of the phrases I hated most as a developer.
Same as before.
Maintain the status quo.
Apply the existing policy.
Words that no one ever wrote down what they actually meant.
"What is the existing policy?"
I muttered to myself.
Even the AI couldn't figure it out if I pasted the document into it.
The AI could only read what was in the document.
It didn't know anything that wasn't in the document, even less than me.
I searched for old tickets.
Three years ago.
Five years ago.
I changed the search terms.
Points.
Coupons.
Promotion.
Points excluded.
An old ticket from a long time ago came up.
Affiliate promotion coupon use will not accrue points.
I opened the content.
The person in charge had already quit.
There were several comments.
At the very bottom, there was a short sentence.
As a result of planning discussions, point exceptions will only apply to some affiliate coupons. Subsequent policy organization is planned.
Subsequent policies did not appear to be organized.
I checked the coupon code.
The problematic coupon was one of the affiliate coupons created at that time.
"Found it."
I said without realizing it.
A young developer pushed his chair and came closer.
"What is it?"
"It's not a bug."
"Huh?"
"Originally, this coupon doesn't accrue points."
"But why did the ticket come in as a bug?"
“The planning team probably doesn’t know about this policy right now.”
He looked at the screen for a moment and said,
"Then the document must be wrong."
"There is no document."
"How do you even find this?"
I stopped to answer.
How did I find it?
There wasn't any special method.
It was just that I knew this kind of thing had happened many times before.
If the code is correct but the result is strange, you have to look outside the code.
And behind the words 'existing policy,' there's usually something unexplained.
"You learn it when you do it for a long time."
After saying that, I realized I sounded like my senior developers I disliked.
The young developer laughed.
"That's the least helpful answer."
"You're right."
I laughed too.
I wrote the investigation results on the ticket.
Linked related past tickets and noted that the current policy and document content were different.
Tagged the person in charge of planning.
A reply came shortly after.
I'll check it out.
And about an hour later, another comment was added.
Existing exception policy has been confirmed to be valid. Closing as not a bug.
I closed the ticket status.
I didn't change a single line of code.
The morning was gone.
In the past, on days like this, I would have felt like I hadn't done anything.
Not anymore.
I learned a long time ago that not changing anything can also be part of a developer's job.
There were many cases where it was better not to fix something than to fix it incorrectly.
In the afternoon, there was a code review for another task.
It was code written by a young developer.
There were traces of AI usage.
The code was clean.
The method names were good, exception handling was in place, and there were test codes.
It was different from the code that junior developers used to write.
It was still a little strange that a junior developer could write this kind of code from the beginning.
I read the code and stopped at one point.
External API calls were set to retry three times if they failed.
It seemed reasonable just by looking at the code.
I commented.
This API is a payment approval API, so automatic retry may result in duplicate approvals.
A reply came a few minutes later.
AI suggested retrying for network error handling, so I added it. I'll check it out.
I stared at the monitor for a while.
He wasn't wrong.
Retry was a common method for network errors.
However, not all calls should be retried.
It was hard to blame the AI for not knowing that.
We just didn't tell it.
A little later, the young developer came to my desk.
"Senior, I think removing the retry is the right thing to do."
"Yeah. Or I should check if it's been approved through the lookup API first."
"But isn't this in the documentation?"
"It might be."
"Where?"
"I need to search for it too."
That friend laughed.
"So we're searching again after all."
"Yeah."
In the past, I searched because there was no material.
Now, I search because there's too much material.
The documents were on the wiki, tickets had accumulated for years, and code was split across dozens of repositories.
There were meeting records, messenger logs, and design documents.
It was better than not having any.
It was definitely better.
But often I still didn't know where the answer I needed was.
In the afternoon meeting, there was discussion about a new development process.
The person in charge shared the screen and explained.
"Going forward, please write a technical review document before starting development. Please include impact analysis and test scenarios as well."
Someone asked.
"Even for simple fixes?"
"In principle, yes."
"Even for changing a single phrase?"
Laughter broke out in the meeting room.
The person in charge also laughed.
"Well, that depends on the situation."
I laughed hearing that.
In the end, it always depended on the situation.
Rules had increased, procedures had become more detailed, and tools had become much better.
But in the end, it always came down to similar words.
Depending on the situation.
If there's no impact.
If necessary.
Appropriately.
In the end, it was people who had to make those judgments.
Around the time I was leaving work, the team lead sent me a message.
Was today's point task handled?
I replied.
It wasn't a bug, it was an existing exception policy. I left the details in the ticket.
A reply came shortly after.
As expected, you're really good at finding these kinds of things.
It was praise.
I sent a ^^
And I looked at the screen for a moment.
I'm better at figuring out why an old system is the way it is than creating new systems.
Sometimes I got confused whether that was praise or not.
As I was about to close my laptop, the AI window caught my eye.
The logs and questions I had pasted that morning were still there.
Five possibilities.
All plausible, all wrong.
I playfully typed one last question.
If the code has no problems but the results are strange, what should I check?
A long answer came back.
Data.
Configuration.
External systems.
Cache.
Deployment environment.
Business rules.
One more line was added at the end.
In particular, it's important to check if there are any undocumented business rules or legacy exception conditions.
I laughed while reading that sentence.
"Now you know too."
