DEV Community: June

On My Japanese Team, the Retro Never Names a Name

June — Mon, 24 Aug 2026 12:13:42 +0000

I run sprint retrospectives on a small, fully remote Japanese team, and if you dropped into one, the first thing you'd notice is what's missing: nobody points at anybody. Not the product owner, not the scrum master, not the engineers. Problems get raised — real ones — but they're always aimed at the process, never at a person. It isn't a rule written down anywhere. It's just how the room works.

I've spent about twenty years on Japanese dev teams, so this reads as normal to me. But I've watched engineers from other places sit through their first Japanese retro and come away unsure whether anything honest actually happened. It did. You just have to know where to look.

The shape of the hour

We run it on a shared board, in a fixed order.

First, before anyone writes anything, we go around and each person says a few words out loud — just a general impression of the sprint. It's a warm-up, but it also sets the temperature. Then everyone gets ten or fifteen minutes of quiet time to write cards on the board: Keep and Problem. Writing first, in silence, matters more than it looks. It means the quieter people put the same number of cards up as the loud ones, and nobody's opinion gets anchored by whoever would have spoken first.

Then we read through them, cluster them, and vote.

The "Keep" column is mostly thank-you notes

Our Keep column is usually the fullest one, and a lot of the cards are, plainly, thank-yous. "Thanks to X for helping me get unstuck on the deploy." "Grateful someone picked up the review while I was out." Gratitude, written down, to specific teammates.

It would be easy to read that as fluff — retro theater that pads the board while avoiding the hard stuff. I don't think it is. On a team where you're careful about pointing at people for problems, the Keep column is where naming a person is not only allowed but encouraged, as long as it's positive. It's the counterweight. You spend the sprint being indirect about what went wrong; the retro gives you a sanctioned place to be direct about what went right, and who made it go right. It keeps the ledger balanced.

Problems point at the process, not the person

When we get to Problem cards, the names come off.

The product owner, the scrum master, and the engineers all write the same way here: describe the problem, not the culprit. So a card doesn't say "the PO keeps changing his mind." It says something closer to "requirements shifted mid-sprint a few times, which made it hard to keep the scope stable." Same information. No target.

This isn't people being conflict-averse to the point of dishonesty. The problems are real and they land. A couple of examples, phrased the way they tend to go up:

Acceptance criteria were unclear on some tickets, so work got built one way and then reworked.
Reviews bunched up at the end of the sprint and turned into a bottleneck.

Everyone in the room usually knows which decisions and which people those cards are really about. But because the card is phrased as a process problem, the conversation stays about the process — how to tighten up acceptance criteria, how to spread reviews across the sprint — instead of turning into a defense of, or an attack on, one person. On a Japanese team, that framing is what makes it safe to raise the thing at all. Take the name off, and the hard problem can actually be discussed.

It helps that the cards are written in Japanese, because the language does half of this for you. Japanese lets you describe something going wrong without a grammatical subject at all — 〜になってしまった (it ended up that way), 〜が発生した (an issue arose), or a plain passive where the actor just drops out of the sentence. In English you have to work to keep a person out of "the requirements kept changing." In Japanese, leaving them out is the path of least resistance. The grammar is already pointed at the process, so the writer doesn't have to make a diplomatic choice — the default phrasing is the diplomatic one.

Voting turns problems into Try

We don't write Try cards up front. We derive them.

Each person gets two or three votes to spend on the Problem cards, and we take the top two or three by vote into the next sprint as our Try items. It's a simple filter, but it does something useful: it means the problems the team feels, not just the ones the loudest person feels, are the ones we act on. The flip-flopping-direction card and the PO-review card both won votes, and both became Trys.

Where it falls apart

The retro works. Real problems get surfaced, voted on, turned into Trys. Then not much happens to them.

They get turned into backlog items — PBIs — with good intentions, and they sit there. The pile of process improvements we all voted for and none of us has had the capacity to pick up just keeps growing. We're good at diagnosing the sprint. We're worse, the next sprint, at remembering what we diagnosed. And I run these retros, so that pile is at least partly mine. That part probably isn't Japanese at all — I think that one's everywhere.

TL;DR

On a Japanese retro, Problem cards describe the process, never the person — "acceptance criteria were unclear," not "so-and-so wrote vague tickets." Removing the name is what makes the hard problem safe to raise.
Japanese grammar helps: you can describe something going wrong with no subject at all (〜になってしまった, 〜が発生した, or a plain passive), so the default phrasing already points at the process rather than a person.
Writing cards silently first, on a shared board, levels the room so quiet members contribute as much as loud ones.
The Keep column is full of thank-yous to specific teammates — the sanctioned place to be direct and positive about people, balancing the indirectness everywhere else.
Try items are derived, not written up front: everyone gets 2–3 votes, the top Problems become next sprint's Try.
Problems get raised fine; the weak spot is follow-through — Trys pile up as backlog items faster than they get closed.

Our Daily Stand-up Is 15 Minutes. It Has Never Once Been 15 Minutes.

June — Sun, 16 Aug 2026 00:36:42 +0000

Ten in the morning. The daily stand-up starts on time, which turns out to be the last thing about it that goes to plan.

We're eight developers on a scrum team, all remote. The meeting is boxed at fifteen minutes, and everyone knows it — it's right there in the calendar invite. Yet most days, around the point where the clock says fifteen, we're maybe halfway down the list of people, someone has just said the Japanese equivalent of "well, about that," and the next twenty minutes write themselves.

I've watched this happen for long enough that I've mostly stopped reading it as a failure. It behaves more like weather. So rather than argue with it, I want to describe it: what actually pushes a Japanese scrum stand-up to twice its allotted length, seen from inside one.

The shape of the meeting

We rotate the facilitator. A different developer runs it each day, which is a nice flat idea, and also — I'll come back to this — part of the problem.

The vocabulary is almost all English, worn smooth into Japanese. Nobody says "daily stand-up." We say デイリー (deirii). Sprint is スプリント, backlog is バックログ. If you've read anything I've written before, you already know this is how technical words travel here: they arrive in English, get spelled in katakana, and stay.

The flow itself is ordinary. Each person covers what they did yesterday, what they're doing today, and anything they're stuck on or need to share. The current Scrum Guide has actually dropped the old "three questions" framing in favor of whatever structure the team likes, but in practice most teams I've seen still land on some version of yesterday-today-blockers. Ours does. On paper it's fifteen minutes of eight people giving short status.

In practice, two things reliably blow past the box.

Reason one: no one in the room can end your sentence for you

Scrum is deliberately flat. There's no lead calling on people, no manager steering, and on our team the facilitator is just whoever's turn it is. That flatness is the point — and it's also why the meeting has no brakes.

When someone starts explaining a problem in more detail than the slot allows, somebody has to decide to cut it short. On a team with a clear owner, that person does it: "let's take this offline." On ours, the facilitator is a peer who'll be back in the normal rotation tomorrow, with no particular standing to shush anyone. So they usually don't. And the rest of us, honestly, don't either. There's a strong instinct here to let a person finish, to not talk over them, to wait for a natural gap that a genuinely stuck engineer never quite reaches.

I don't want to stretch this into a claim about the whole country — I only sit in one team's stand-up. But I'll say the softer version, because I think it holds: meetings here tend to run long, opinions tend to arrive wrapped in hedges, and a firm conclusion can be slow to surface. Put that tendency inside a structure that removes the one person with the authority to say "stop," and fifteen minutes was never realistic.

Reason two: the stand-up is where the cross-team stuff lands

The status part is fast. What stretches the meeting is everything that isn't strictly our own work: coordinating with another team, chasing an answer we're blocked on, hashing out who owns a handoff that sits between two groups. None of that fits in a status update, and none of it belongs to any single person's "today."

The reason it ends up in the stand-up anyway is simple arithmetic. If we don't deal with it here, while the relevant people happen to be in the same call, it becomes a separate meeting later — a new invite, a new fifteen minutes that will also run long, for the same reasons. Given that trade, letting the stand-up absorb it is often the cheaper option. So the fifteen-minute status meeting quietly does a second job as the place where the team's external friction gets worked out.

So is it broken?

By the letter of it, yes. The Scrum Guide is blunt: the Daily Scrum is a fifteen-minute event. We are not a fifteen-minute event. If you scored us against the framework, we'd lose points.

I've come around to a less tidy view. When we run over, it's usually because the meeting is doing work that has to land somewhere and no one has built a better place for it — the cross-team coordination is genuine, and dropping it doesn't make it go away. The reluctance to cut a struggling teammate off mid-thought is, if I'm honest, not a habit I'm in a hurry to train out of the team. Could we tighten it — hard fifteen-minute cap, park everything else into a follow-up? Probably. Some days I want to. But every version of "fix it" I've tried just moves the same half hour to a different slot on the calendar, and now it's two meetings instead of one.

So for now it stays a thirty-minute stand-up, and I've stopped pretending that's a temporary state.

If you join a Japanese scrum team from somewhere the stand-up really does end at fifteen minutes, this is the part worth knowing in advance: block out thirty. The meeting is carrying more than its name suggests — the coordination that doesn't fit anywhere else, and a room full of people who'd rather run over than cut you off. Nobody's disorganized; the stand-up is just quietly doing two jobs. Once you stop expecting fifteen, it's a pretty good half hour.

Sources

Scrum Guide (2020), Ken Schwaber & Jeff Sutherland — Daily Scrum is a 15-minute event; the older "three questions" structure is no longer prescribed. https://scrumguides.org/scrum-guide.html

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.