DEV Community: June

The First Report Isn't the Full Story — and It's Not Supposed to Be

June — Wed, 05 Aug 2026 23:58:31 +0000

Something is wrong in production. You caught it yourself, or someone pinged you, and now you're heads-down trying to work out what happened. The instinct — the one I had for years — is to stay quiet until you have something worth saying. Find the cause, confirm a fix, then report it in one clean message so you don't look like you're flailing in public.

On a Japanese dev team, that instinct quietly works against you. The complete report you're holding back for is the wrong first deliverable. What the team wants before anything else is a message that's fast and mostly empty: what broke, the fact that you're on it, and a promise that more is coming.

The word for that first message

There's a specific vocabulary for this, and it's worth knowing because you'll see it fly past in a channel the moment anything goes sideways.

The core word is 一報 (ichihō) — literally "one report," but in practice "the first heads-up." Sometimes you'll see the fuller 第一報 (dai-ichi-hō), "the first report," especially for something serious. What follows it is 続報 (zokuhō), the "follow-up report." So the shape of an incident, in Japanese, is one 一報 followed by as many 続報 as it takes.

The 一報 is not a summary of the problem. It's closer to a flare. Its whole job is to get the fact of the incident in front of people while you still don't understand it.

Why the half-empty message wins

This runs on the same logic as 報連相 (hōrensō), the reporting habit that governs a lot of Japanese team communication: a problem nobody has heard about is one nobody can help you with yet. During an incident that logic just gets sharper, because minutes compound. Every minute you spend going from "something's wrong" to "here is the full root cause" is a minute nobody else knows to check the dashboard, warn support, or notice they touched that service an hour ago.

A fast 一報 buys you the team's attention early, when it's cheapest to act on. Holding the message until it's complete does the opposite: it keeps the problem private for exactly the window when sharing it would have helped most. On the teams I've worked on here, the engineer who says "I don't know the cause yet, but I've told everyone" is read as more reliable, not less, than the one who went dark and came back an hour later with a tidy writeup.

What the first report actually says

Here's a first report you could drop into a channel the moment you notice something:

取り急ぎ一報です。本番でエラーが出ています。今、調査中（ちょうさちゅう）です。分かり次第（わかりしだい）、続報します。
"Quick heads-up: there's an error in production. I'm looking into it now, and I'll follow up as soon as I know more."

Four small pieces are doing the work.

取り急ぎ (toriisogi) means roughly "in haste" — it's the standard opener that signals "this is fast and incomplete, and that's on purpose." It gives you permission to send before you're sure. When you lead with 取り急ぎ, nobody expects the message to be complete.

一報です (ichihō desu) names the message for what it is: this is the first report, not the analysis.

調査中 (chōsa-chū) means "under investigation." The 中 (chū) on the end of a word is a useful little tag for "in progress" — 対応中 (taiō-chū), "handling it now," works the same way. It tells people you're actively on it without claiming you've solved anything.

分かり次第 (wakari-shidai) means "as soon as I know." X次第 is "the moment X happens," and here it sets the expectation that more is coming without promising a time you can't hit.

Notice what the message doesn't contain: a cause, a fix, an ETA, or an apology paragraph. Trying to include those is what makes people wait too long to send. The 一報 is allowed to be thin.

The detail goes in the follow-ups

Once the flare is up, the 続報 is where the real information lands, in whatever increments you actually have it:

続報です。原因（げんいん）が分かりました。〇〇の設定ミスでした。今から修正（しゅうせい）します。
"Update: found the cause. It was a misconfiguration in [X]. Fixing it now."

Then another when it's fixed, and usually a short close so people know they can stop watching:

復旧（ふっきゅう）しました。ご心配（しんぱい）おかけしました。
"It's recovered. Sorry for the worry."

That cadence — one thin 一報, then 続報 as facts arrive, then a clear "it's over" — is the whole pattern. The completeness you were tempted to front-load just gets spread across the follow-ups instead, arriving as you learn it rather than all at once at the end.

The shift that took me longest was trusting that an incomplete first message doesn't read as sloppy here. It reads as reliable. My own instinct still wants to go quiet and come back with the whole story tied up in a bow, and I have to talk myself out of it every time. The hard part was never writing the perfect incident summary. It was getting comfortable saying, out loud and early, "here's what I don't know yet."

If finding the right words for moments like this is the part that trips you up, I put together a course on exactly this kind of workplace Japanese for engineers: Japanese for Software Engineers (free with this coupon through Aug 21).

Japan Set a Government Deadline for Its Legacy Code. It Was Last Year.

June — Sun, 02 Aug 2026 13:11:33 +0000

Every engineer has met a cursed codebase. The file nobody edits without a small prayer. The function with a comment that says "DO NOT TOUCH" and no explanation of why. The module that works, mysteriously, and would apparently stop working if you looked at it too hard.

Japan has these too. The difference is age and scale. A lot of the systems quietly running this country — banks, insurers, government, manufacturing — were built in an era when the people who wrote them expected to maintain them until retirement. Some of those people have now retired. The systems have not.

I've spent about two decades as an engineer here, and my time has been split between two worlds. A lot of it has been new development — the kind of project where you get to make the mess yourself. But I've also worked inside the old systems, and the two feel nothing alike. Building something new is engineering. Working in a decades-old system is closer to archaeology: you're not writing software so much as excavating it, one layer at a time, trying to reconstruct the intentions of people you'll never meet.

The strata

Open an old Japanese enterprise system and you can read its history like sediment.

The bottom layer is the original build, often startlingly clean, because one team designed it under one coherent idea. Above that sits a decade of "just add a flag here" changes, each reasonable on its own, none of them aware of the others. Near the surface you find the recent panic layer: the workarounds added when something broke in production and had to be fixed by morning.

The comments are their own excavation. They're in Japanese, which is fine, except the variable names are in romaji — Japanese words spelled in the Latin alphabet — so you get things like torihiki_flg (transaction flag) sitting next to a comment explaining a business rule that the company stopped following in 2011. The rule is gone. The flag is load-bearing. Nobody knows why, and the person who did know is not answering email, because they left. I have lost real days to flags like that.

There's a phrase Japanese chefs use for a sauce that's been topped up and reused for generations: 秘伝のタレ (hiden no tare), the "secret sauce." It's meant as praise — depth you can't fake or rebuild from scratch. Legacy code is the accidental version of the same thing. Twenty years of additions, and no living person understands the whole flavor.

Why the digs run deeper here

Cursed legacy is universal. But a few things make the Japanese version particularly deep.

The big one is structure. A large share of enterprise systems here were built not by in-house engineers but by SIers — systems integrators — often through several layers of subcontracting. The company that owns the system, the company that designed it, and the company that maintains it today can be three different companies, across a gap of many years. The people who made the decisions and the people who now live with them were never in the same room. Knowledge that would have been tribal on an in-house team instead evaporated across contract boundaries.

The other thing is that Japan runs a lot of industries where "we'll rewrite it eventually" was never really on the table. Core banking, public infrastructure, long-lived manufacturing lines — these were built to run for decades, and they have. Stability was the whole point. The cost of that stability is that the code got old in place.

The cliff the government named

This got serious enough that the state gave it a name.

In September 2018, Japan's Ministry of Economy, Trade and Industry (METI) published a report that coined a phrase now familiar to everyone in the industry here: 2025年の崖, "the 2025 digital cliff." The argument was blunt for a government document. If Japanese companies didn't modernize their aging systems, the report warned, the country could lose as much as ¥12 trillion a year — very roughly $80 billion — between 2025 and 2030, from the sheer drag of maintaining the past.

The supporting numbers were just as pointed. By 2025, it projected, around 60% of Japanese firms' core systems would be 21 years or older. It warned of a shortfall of roughly 430,000 IT workers. And it described the legacy problem in three words that any archaeologist would recognize: 複雑化・老朽化・ブラックボックス化 — complex, aged, black-boxed. Its most quotable claim was that companies risk spending over 90% of their IT budgets just keeping the old thing alive, with nothing left for anything new.

Here's the part I find worth sitting with: that deadline has passed. We are now on the far side of the cliff the report named. Some organizations climbed down carefully. Many are still standing at the edge, patching, because the systems in question are the ones you cannot turn off to renovate. You don't get to close the bank to remodel the vault.

How you actually excavate

The archaeology framing isn't just a metaphor for how it feels. It's also, genuinely, how you should approach the work.

Read before you run. The instinct on a new codebase is to run it and poke at the behavior. On something this old, behavior lies — half of what it does is compensating for a problem that no longer exists. Read first. Treat the code as a document about the past, not a description of the present.

Distrust the strata. When you find something baffling, resist the urge to assume the original author was an idiot. The odd choice usually made sense against a constraint you can't see anymore — a hardware limit, a vanished business rule, a bug in a dependency three versions back. The weird code is an artifact. It records a condition, not a mistake.

Dig for the "why," and then write it down. The single most valuable thing you can add to a system like this isn't a refactor. It's a note explaining why something is the way it is, so the next person to dig here starts one layer further down than you did. Most of the pain in legacy work is knowledge that was never recorded. You can't fix the whole thing, but you can stop the erosion.

There's a new tool on the dig, and it's the first genuinely new one in a while. Feeding a bewildering old function to an AI model and asking "what does this actually do, and why might it have been written this way?" turns out to be a decent excavation technique. It won't recover the lost business context — no model knows why your company abandoned a rule in 2011 — but it's very good at reading a wall of torihiki_flg logic and handing you a hypothesis to test. Think of it as a sharper trowel. It digs faster; it still can't tell you what the layers mean. That part's on you.

The part that stays with you

The strange reward of this work is that it teaches you to read software as human behavior. Every ugly patch was somebody's Tuesday-night deadline. Every dead flag was a rule someone once cared about enough to encode. You start to see the codebase less as a machine and more as a place people passed through, each of them leaving the problem slightly more habitable than they found it, and slightly harder to understand.

Japan's cliff has a date on it. But the truth underneath the policy report is one every engineer eventually meets: the past doesn't get cleaned up. It gets inherited. The job is just to leave a better map for whoever digs here next.

Sources

Facts on the METI "2025 digital cliff" report (in Japanese):

TL;DR

Maintaining old Japanese enterprise systems is less like engineering and more like archaeology: you excavate intent from people you'll never meet.
The layers run deep here because of the SIer/subcontracting structure (builder, owner, and maintainer are often different companies) and industries built to run for decades.
In 2018, Japan's METI named "the 2025 digital cliff": up to ¥12 trillion/year in losses (2025–2030), ~60% of core systems 21+ years old by 2025, a ~430,000 IT-worker shortfall, and legacy that's "complex, aged, black-boxed."
That deadline is now behind us. Many systems still sit at the edge, because you can't switch them off to renovate.
How to dig: read before you run, treat weird code as an artifact (not a mistake), and record the "why." AI is a good new trowel, not a replacement archaeologist.

On a Japanese Dev Team, 'No News' Is Bad News

June — Wed, 29 Jul 2026 13:42:32 +0000

On a lot of teams, silence is fine. If your manager doesn't hear from you, they assume the work is moving and leave you alone. No news is good news.

On a Japanese dev team, the default runs the other way. If nobody has heard from you, the quiet itself starts to feel like a risk. Not because anyone thinks you're slacking. A problem nobody has heard about is simply one nobody can help you with yet. So the most valued habit is speaking up early, before anyone asks, while the work is still half-done — not saving up a clean report for the end.

There's a word for the whole bundle of habits around this, and you'll hear it constantly.

Hōrensō: three moves in one word

ほうれんそう (hōrensō) is a made-up word stitched from the first sounds of three others. It also happens to sound exactly like the word for spinach, which is why the name sticks. The term itself is plain business vocabulary, used in completely serious settings — the spinach resemblance is just a memory hook, not a punchline. The three pieces are:

報告 (hōkoku): reporting. Telling someone about a result. It looks backward at something finished.
連絡 (renraku): informing. Passing along a plain fact, with no opinion and nothing to decide.
相談 (sōdan): consulting. Asking for input before you decide, so it looks forward.

A quick way to sort them: do you need someone's opinion before you can move? That's sōdan. Is it just a fact the team needs to know? That's renraku. Are you reporting an outcome? That's hōkoku.

Here's each one in a normal work moment.

Reporting something you finished:

昨日お願いされた資料、完成しました。共有フォルダに置いておきます。
"The document you asked me for yesterday is done. I'll put it in the shared folder."

Short, backward-looking, no opinion attached. It names the task, says it's done, and says where to find it.

Informing the team of a fact:

明日、サーバーメンテナンスがあるので、朝9時まで一部の機能が止まります。
"There's server maintenance tomorrow, so some features will be down until 9 a.m."

Pure information: what's happening, when, what it affects. No request buried inside it.

Consulting before you commit to a direction:

ちょっとご相談があるのですが、今お時間よろしいですか？この設計、2つの方法で迷っていまして。
"Could I run something by you — do you have a minute? I'm torn between two approaches on this design."

The key verb there is 迷っていまして (mayotte imashite), "I'm torn between options." It asks for an opinion without demanding an answer, which is exactly what makes it a consultation instead of a decision you're announcing.

The part that actually matters: go first

You could memorize all three words and still miss the point of them. The real habit sitting on top of hōrensō is 先回り — going first. A short heads-up sent early beats a perfect report sent late.

This is the move that feels wrong if you come from a "don't bother people until it's done" background. On a Japanese team, sharing work that's still in progress is treated as a courtesy. You're giving people the time to react while there's still room to react.

The phrase that unlocks it is this:

まだ途中なんですが、今の進捗だけ先にお伝えしておきます。
"I'm still in the middle of it, but let me share where things stand so far."

The load-bearing part is the opener, まだ途中なんですが (mada tochū nan desu ga), "I'm still in the middle of it, but…". It gives you permission to report something incomplete. Once you can say that, you can surface a half-finished status, a blocker you just hit, or a risk you see coming, all without waiting for a tidy conclusion. If you learn one phrase from this whole idea, learn that one.

Why it works this way

None of this is about being formal for its own sake. The logic is mundane but real: catch a shaky design decision on Tuesday and it costs a conversation; catch it after it ships and it costs a sprint. Reporting in progress, passing facts along, asking before deciding — they're all ways of keeping information moving so nothing festers in a corner where only you can see it.

Once you read it that way, the instinct to go quiet and "come back when it's solved" is the one habit worth dropping. The quiet is the thing your team is trying to avoid.

The takeaway

If you're joining a Japanese dev team, don't save your updates for the finish line. Report what's done, pass along what's true, ask before you decide — and whenever you can, say it early, even mid-task. "まだ途中なんですが" is the phrase that lets you do the last one, and it's the one nobody writes down for you.

This is one lecture from a course I built called Japanese for Software Engineers — the workplace Japanese that only shows up once you're actually on a team: stand-ups, code reviews, incident calls, and the reporting habits above. If it's useful to you, it's free through August 21, 2026: https://www.udemy.com/course/japanese-for-software-engineers/?couponCode=ABAD7DB87460AA4E2853

TL;DR

On Japanese dev teams, silence reads as risk, not reassurance. Sharing early is the valued habit.
ほうれんそう (hōrensō) = 報告 report a result / 連絡 pass along a fact / 相談 ask before deciding.
Sort them by intent: need an opinion first → sōdan; just a fact → renraku; an outcome → hōkoku.
The real skill is 先回り (going first): a quick early heads-up beats a perfect late report.
The one phrase to keep: まだ途中なんですが ("I'm still in the middle of it, but…"), which lets you report unfinished work.

The Japanese You Learned Won't Help You Say 'git push'

June — Sat, 25 Jul 2026 10:51:15 +0000

A while back, an engineer who'd recently joined a team here said, in Japanese, that he had "pushed" his code. Except he didn't use the word "push." He'd looked it up, found the Japanese verb for physically pushing something, and used that instead. 押しました. Literally, "I pushed it," the way you'd push a door.

The room went quiet for a second. Not because it was wrong exactly, but because nobody says that. Everyone understood him eventually, but there was a visible half-second of "...pushed what?"

His Japanese was genuinely good. That was the strange part. He'd studied hard, he knew the grammar, and he'd done exactly what a textbook trains you to do: take the English word, find the Japanese equivalent, use the Japanese equivalent. For almost every situation, that's the right instinct. For technical vocabulary on a dev team, it's the one place it backfires.

Japanese dev teams speak in katakana English

In a Japanese engineering team, most of the technical verbs are just English words, pronounced in katakana, dropped into Japanese sentences.

You don't translate "push." You say プッシュ (pusshu). You conjugate it with a Japanese helper verb and move on:

プッシュしました (pusshu shimashita): "I pushed."

Same for almost the entire daily vocabulary of the job:

マージする (māji suru): to merge
デプロイする (depuroi suru): to deploy
コミットする (komitto suru): to commit
リリースする (rirīsu suru): to release
レビューする (rebyū suru): to review
リファクタリングする (refakutaringu suru): to refactor

The pattern is almost mechanical: take the English technical verb, say it in katakana, add する (suru, "to do") to make it a verb, then conjugate する normally. プッシュする becomes プッシュします becomes プッシュしました. You already know these words. You just have to trust that the katakana version is the correct one, not the "real" Japanese translation you'd find in a dictionary.

That trust is the hard part, because it runs against everything language study teaches you. The dictionary translation of "merge" exists. It's 統合する (tōgō suru). It's a perfectly real word. But if you say "この機能を統合しました" in a stand-up, you'll sound like you're presenting a corporate merger, not describing a git operation. The katakana word is the one that belongs in the room.

Why it works this way

Software as a field grew up in English. The tools, the docs, the error messages, Git itself, all in English. When Japanese teams adopted them, they didn't stop to invent native words for every command. They just absorbed the English terms into speech, the way English absorbed "café" or "tsunami." So the katakana isn't some casual shortcut. It's the register the work actually happens in.

The upside is almost unfair: if you know the English word, you already own the Japanese one. The gap is smaller than it looks. The catch is trusting that, which cuts against every instinct language study builds in you. Your brain keeps offering the dictionary translation, and you have to keep turning it down.

A few that trip people up

Not everything is a clean katakana swap, and a few common cases are worth knowing.

Some words have a native form that's genuinely used alongside the katakana one. "To fix" a bug is usually 修正する (shūsei suru), a real Japanese verb, not フィックスする. "A bug" itself, though, is バグ (bagu), straight from English. So you'll hear バグを修正しました (bagu o shūsei shimashita), meaning "I fixed the bug," mixing a katakana noun with a native verb in the same short sentence. There's no single rule; it's just what stuck.

And "push" specifically has one more wrinkle. In casual speech, people often shorten pull request to プルリク (puru-riku). Written in chat it's PR. Said out loud, it becomes puru-riku. So the full sentence in a stand-up might be PR出しました (PR dashimashita), where even 出す (dasu, "to put out / submit") is the native verb doing the work, and PR is read as puru-riku. Nobody spells any of that out for you. You just have to hear it a few times.

The takeaway

If you're learning Japanese to work on a dev team, your instinct to translate is correct almost everywhere except the technical core. There, do the opposite: keep the English word, say it in katakana, and staple する to the end. The engineer who said 押しました wasn't wrong about Japanese. He'd just missed one habit that nobody writes down anywhere, because to the people who already know it, there's nothing to write.

This gap, between the Japanese you study and the Japanese engineers actually speak at work, is the whole reason I built a course called Japanese for Software Engineers. It covers the stuff that only shows up once you're in the room: stand-ups, code reviews, incident calls, and yes, how to talk about your PR without confusing anyone. If that's useful to you, it's free through August 21, 2026: https://www.udemy.com/course/japanese-for-software-engineers/?couponCode=ABAD7DB87460AA4E2853

TL;DR

Japanese dev teams say technical verbs in katakana English, not the dictionary translation: プッシュする (pusshu suru), not the native verb for "push."
The formula is mechanical: English technical word in katakana + する (suru) + normal conjugation. プッシュする → プッシュしました.
The dictionary translations exist (統合する for "merge") but sound out of place at work. The katakana word is the professional register.
A few mix: バグ (katakana noun) but 修正する (native verb for "fix"). "PR" is written PR, said puru-riku.
If you already know the English term, you already know the Japanese one. Trust the katakana.

I'm new to "Dev.to"

June — Wed, 22 Jul 2026 23:44:33 +0000

Hello from Japan. I've been reading DEV for a while and finally decided to stop lurking.

My career

I've spent about 20 years as a software engineer in Japan, mostly backend work in Java and PHP, plus AWS architecture for the last stretch of it. Large systems, the kind with two decades of history and a few modules nobody wants to touch.

Somewhere along the way I also started teaching languages, which I've been doing alongside engineering for the past 10 years. That combination is unusual enough that people ask about it, so: I never left engineering for teaching. I just do both, and they turned out to overlap more than I expected.

Why I started using DEV

Most of what I know is about a place that doesn't get written about much in English.

There's plenty of content about Japan as a travel destination, and a fair amount about Japanese companies as an abstract cultural topic. There's much less about what it's actually like to sit in a Japanese dev team's stand-up, or why the code review comment you just received is more critical than it sounds.

I've watched engineers arrive from other countries and hit the same walls repeatedly. Not language walls exactly. More like: they knew the words, but not what the words were doing. I ended up explaining the same things over and over, one conversation at a time, and it seemed worth writing down properly.

DEV felt like the right place because the readers here are engineers. I don't have to explain what a pull request is before getting to the interesting part.

What I'm currently working on

I recently finished building a course about workplace Japanese for software engineers. Not textbook Japanese. The phrases that actually appear in stand-ups, code reviews, Slack threads, and incident calls, plus the cultural reasoning behind why they're phrased that way.

That project made me realize how much of this knowledge lives only in people's heads, mine included. Which is part of why I'm here.

What I'll write about on DEV

Mostly the intersection of Japanese dev culture and everyday engineering work:

How Japanese teams handle code review, incidents, and decision-making, and why those patterns exist
The gap between textbook Japanese and the Japanese engineers actually use at work (they are surprisingly far apart)
Legacy systems in Japan, which is its own genre of archaeology
Occasionally, working with AI tools on old codebases, because that's what I've been doing lately

If you're an engineer in Japan, thinking about moving here, or just curious how things work on this side, I'd like to hear what you're wondering about. Questions are genuinely useful to me. They tell me what's worth writing.

Nice to meet you all.